We’ve never deprecated a platform in widespread use before, and it
seems prudent to warn users about the upcoming end of support so they
can plan appropriately.
I tried to make this relatively unobtrusive by taking advantage of
the import cache and offering a way to turn it off, but I anticipate
there might still be issues with e.g. `nix shell nixpkgs#…` and
spammy warnings from multiple instantiations of Nixpkgs. I’m
not sure there’s much we can do about that unless we take a
different strategy entirely; `nix shell --impure nixpkgs#…` with a
`~/.config/nixpkgs/config.nix` is about the best UX we can hope to
offer with the restrictions of flakes.
Cargo uses the basename of a JSON target specification in various places
to refer to targets, cc-rs parses the basename to grab target
information. There may be other examples where the basename is relevant.
Instead of fighting these existing conventions, let's just recommend
users provide a rustcTargetSpec, either as a standard name or as a
custom JSON file with the right basename
This adds a useful hook to be used for projects that use stestr,
it is primiative at the moment but covers most scenarios for using
it.
This PR also changes a Python module to start using it, once it
lands, follow up PRs can update all of them to use it tree-wide.
Signed-off-by: Vinetos <contact+git@vinetos.fr>
Providers are the thing I spend most of my time on while admittedly very
few users use it (I can only think of deoplete now) and it's going to disappear anyway.
We have no tests for it because of the previous reasons.
Before this patch:
nix path-info -Sh .#neovim
/nix/store/smd007xlbsx35y42rri5xlqhjgajz9in-neovim-0.11.6 365.0 MiB
After:
nix path-info -Sh .#neovim
/nix/store/4cr60j05l3pirhhrcs5hqb9rzj854n5r-neovim-0.11.6 240.6 MiB
To restore old behavior, pass `{withPython3= true; withRuby = true; }`
to the neovim wrapper.