better workflow for migrating from profile manifest version 3 #177
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#177
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe.
When migrating from nix to lix, a newer profile manifest version might already be in use. This can be worked around by deleting the profile and re-creating it with lix, however this is a cumbersome workflow and not really user friendly.
Describe the solution you'd like
Some kind of backwards migration or compatibility code for nix profile manifest >=3
Describe alternatives you've considered
Leaving it as-is and adding documentation for the workaround
Additional context
this looks like a real quagmire. first
nix profile
itself was made more friendly (why was this index-based to begin with):nix profile: Allow referring to elements by human-readable name #8678
then a new profile version came along to support this:
Make profile element names stable #9656
and after that a whole slew of refactorings and bugfixes that we really don't want to untangle.
not sure what the best way forward is. simply migrating back down from version 3 to version 2 should be possible, but it's going to break the ux of newer
nix profile
versions.Should we support manifest v3 instead?
if we remember correctly that was on the original backports list but we dropped it for being a huge pain in the tail, additionally to being a dependency hell of refactorings needed to pull it in at all. it also had unfortunate interactions with flake url parsing for some fucking reason
Hm… looking at the diff we think we might be able to do it. Should we give it a shot or should we just implement migration from 3 to 2?
As much as maybe nix profile should be removed anyway, it also really shouldn't have been index based to begin with…
undoing a 2->3 migration feels more fraught than implementing v3 support, so if you want to try do go ahead! we mostly didn't at the time because we had no energy to rewrite the patches sufficiently to make them apply, and then discarded the whole thing for being unlikely to affect most users (because nixpkgs doesn't have those features either).
Hm, the upstream PR removed support for specifying stuff via index. I'm wondering if we should also do that? Feels like it could still be handy for scripting or something
Done:
076dfd30c6