-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move four modules to graveyard #10248
Conversation
Just a reminder: Fixes #2796 |
And with |
This is pretty breaking. I can think of at least two of my projects that use By the way, merging your own PR is really bad, especially for something like this... |
/cc @dom96 workaround: this makes things work again:
a few more points:
indeed. A thumbs up means: I like the spirit of the PR, it doesn't mean "I approve this PR after a proper review". |
It was discussed internally previously and approved, I wouldn't merge it otherwise. |
...but, after some more discussion, SMTP and OIDS are back :) (0a2f711) |
@dom96 That's not a good reason to avoid moving modules into graveyard: your projects can simply add a nimble dependency. I have no opinion on
We should implement UUIDs and remove this module |
That's true. And yes, in general I'm happy for this to happen, but I want us to have a good discussion about it. What exactly belongs in a stdlib and what doesn't? One thing I would like to stress though: how are users supposed to know that they can get these modules from graveyard? We need a transition period for these otherwise our users will just get frustrated. @narimiran Instead of removing these modules, can you replace the file's contents with |
that's a big topic and deserves a separate dedicated discussion in a github issue for easy cross-reference
|
|
It was ported from C to Nim and then later MongoDB changed its spec / C implementation, that's why. |
i object to the idea that smtp is not used much in the wild just because libraries on github.com don't need to send email. Nearly every web app will (contact forms, at the least) and some desktop apps will, and i'm guessing you wouldn't hear about it. |
True but regardless of these facts Smtp as an external package not tied to Nim's slow release cycle makes sense. |
hmm, i hadn't thought about that aspect. I see that smtp is not even in the Graveyard repo (anymore?) and is in it's own repo. I guess modules in their own nim-lang repo are planned to be supported going forward. If so, great! |
Yes, that is indeed the case and we try to ensure that the docs still cover these modules. |
Rationale:
These four modules (subexes, scgi, smtp, oids) are poorly documented, not used in the stdlib, there are no tests for them, and aren't much used in the wild.
They will be added to graveyard so they can be installed via nimble.
Please do NOT squash commits when merging, in case one of them needs to be reverted later.