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
emacs-packages: Drop deprecated package sets #66301
emacs-packages: Drop deprecated package sets #66301
Conversation
I think the release note could be better, any suggestions? |
I like the idea (and simplicity) of dropping `emacsPackages` and renaming `emacsPackagesNg -> emacsPackages` in a single PR, but
- I see some `emacsPackages` vanishing without a trace from attrsets (e.g. `scalaMode*`) while their nix files are left in the working tree (I assume they just have different names in MELPA, but then this PR leaves garbage around),
- also, I think, there should be aliases for all the old names.
|
@oxij I made a note of that I see this as an excellent opportunity to clean up years of ad-hoc hacks and derivations.
I'm open to keeping aliases for packages if people are vehemently for it but I really don't want to. |
Well, leaving garbage in the tree until some later PR seems counterproductive to me.
IMHO, ideally, this would be done as a bunch of separate commits replacing old `emacsPackages` with aliases in `emacsPackagesNg` (while removing the original ad-hoc expressions), followed by a rename `emacsPackagesNg -> emacsPackages`.
But given that nobody did that for two+ years, one big rename, as done here, is probably fine. But only when done with aliases.
And while I'm a fan of aliases for backwards compat the current names we have are not matching well to the emacs ecosystem and I would rather drop them once and for all than having to keep aliases around for an eternity.
Well, yes, but sudden drops of attributes are uber-annoying when you need to build the same `configuration.nix` against several revisions of `nixpkgs`. Which is a rather common use case: e.g., you want to build against both latest release and `master`, you want to bisect over a span of revisions of `nixpkgs`, etc etc.
|
currently running my system on this PR .. everything seems fine, so far. I have been on emacsPackagesNg for some time though .. |
a1e71e8
to
ad76899
Compare
OK fair enough, I've dropped all old packages in this PR. I'm still on the fence about aliases, I don't think that the bisect use case is a good enough reason. I aim to merge this before the 19.09 release. |
OK fair enough, I've dropped all old packages in this PR.
Thanks.
I'm still on the fence about aliases, I don't think that the bisect use case is a good enough reason.
But isn't the ability to build the same `configuration.nix` against 19.03, master, and future 19.09 a good reason?
|
cc @ttuegel @bendlas @matthewbauer What do you think about the alias situation? |
I'm a believer in the "don't break api" principle, so if somebody is willing to comb through the package sets, I'm for leaving the aliases in place, along with a deprecation warning. |
b0f7eb4
to
aa9f330
Compare
I want to add that I'm personally not a fan of this and I think we should eventually drop these aliases to closely match the eco-system rather than relying on some ad-hoc names created years ago.
aa9f330
to
b3d6dd5
Compare
I have added the requested aliases, even though I'm personally not a fan. |
Not sure if someone is still listening here but just in case: It seems that the |
Although they are actually different packages, so that might not be a good idea after all |
I just went ahead and fixed |
Motivation for this change
These have been deprecated for a long time and I think we are doing our users a disservice by still keeping them around.
I tried porting over all packages that were not in any generated sets but some of these are broken.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @mdorman @thoughtpolice @peti @samuelrivas @etu
Note that I've left all derivations on purpose. I will make a follow up PR taking care of those once this one is merged.