Lock file and Environment update and installation flags.

[ruben-arts]

The current default behavior of almost all pixi commands is to validate/update the lock file and the environment affected by the command. For example:

• add, remove modify the manifest (pixi.toml/pyproject.toml)
• Solve the environment and save it to the lock file (pixi.lock)
• Update/install the environment (in .pixi/envs)

However, in some cases, especially in CI, the last two behaviors can be undesirable. To address this, we've added these flags:

• --no-lockfile-update: Don't check the lockfile and thus don't install what can't be verified.
• --frozen: Skip the validation and update of the lock file.
• --no-install: Skip the installation or update of the environment.

After discussing with @olivier-lacroix, we realized we had different understandings of the flag names. So, I'm seeking more input.

Questions:

1. Is the current default behavior appropriate?
2. Are the flags named correctly for what they do?
3. Should we add or remove any flags?

I'm looking for good ideas the community can agree on! 🫂

Related:

• #1669
• #1683
• #1131

---

My current answers:

• Yes, we should always ensure the environment and lock file are up-to-date with the manifest after modification. But it should be easy to avoid this when necessary.
• I'm not a fan of --no-lockfile-update and would prefer something more specific like --only-manifest. Alternatively, using --frozen --no-install together could tell pixi not to check the lock file and not install the environment.
• Consider removing or modifying the --no-lockfile-update flag.

[tdejager]

Can you maybe clarify what you mean with?

--no-lockfile-update: Don't check the lockfile and thus don't install what can't be verified.

Does that mean that it does install what was verified (so like a subset of packages or something), or does not verify and install anything, which sounds like a no-op to me?

[ruben-arts]

It works by avoiding all the solve and installation steps. So you asking this question verifies that it's not a good name ;)

[tdejager]

It works by avoiding all the solve and installation steps. So you asking this question verifies that it's not a good name ;)

So it only runs satisfiability? :)

[olivier-lacroix]

My understanding was that —no-lockfile-update led to ‘just’ modifying the manifest.

As it is a flag to pixi add / remove, checking satisfiability / consistency would not make too much sense I think. Would you guys see a value in adding the behaviour of --locked to pixi add or pixi remove ?

[olivier-lacroix]

@ruben-arts , I wouldn’t see any problem with replacing —no-lockfile-update with —only-manifest if people find it clearer.

My doubt / question relates to replacing that flag with the combination —frozen —no-install: in that case, what would pixi add —frozen do? add the package to the manifest, and install the unmodified lockfile to the prefix? This would be quite confusing I think.

[olivier-lacroix]

@ruben-arts a tangent remark: I don’t find the difference between —locked and —frozen very obvious: I have to check the help each and every time to know which is which 😅.

I think maybe keeping a single of those and having an additional —no-check flag to bypass consistency check could work? Or find flag names that are more self-explanatory?

[pavelzw]

I personally never had understanding what the different CLI flags meant. I would like to keep --locked and --frozed as they are as it's easier for people who already know cargo. (also, i can't think of better names)

I find --no-install to be quite clear in what it does.
I personally can't think of any use case where I would want to use --no-lockfile-update 🤔 Can you think of any?

[olivier-lacroix]

Agreed. It can be useful for CI / automation scenarios

[pavelzw]

Maybe --skip-solve?

[tdejager]

Except --no-install is totally unclear if you have pypi-dependencies :P

[tdejager]

Haha now that I'm trying to think of names, I do get a better idea why --no-lockfile-update was chosen.

[tdejager]

We could also go in the other direction and make it configurable with stages or something --skip=solve,install.

Not sure, just thinking out loud.

[jonmoore]

Regarding "Is the current default behavior appropriate?" it wouldn't have been my choice to run these checks, etc. on almost every pixi command. For me, these basically add delays (albeit small) and distractions (i.e. irrelevant animated command output) during my use of pixi.

I would not suggest changing the defaults, as this would be a compatibility break. I would though find it helpful if there was a simple project-level way to configure whether these checks, updates, etc. are invoked by default.