Deprecate --dev related switches

[qmarcou]

Description

This PR is a follow up of #641 .

In a nutshell --dev/--no-dev switches are incorrectly documented, inconsistent, as well as redundant (albeit with some clashes) with the --extra CLI.

Changes made deprecate explicitly all --(no-)dev(-dependencies) by raising a meaningful exception.

Limits:

• the deprecation is not in pytest tests. In fact there were no prior tests concerning "--dev" switches, there is a dedicated but unused pytest fixture: https://github.com/conda/conda-lock/blob/f753f705f38f8166e2dab9365ed5d87d0b90341d/tests/test_conda_lock.py#L356-L364 It seems there is currently no tests regarding the --extra switches behavior.
• ongoing discussion about the default behavior of --extras in #641

[netlify[bot]]

✅ Deploy Preview for conda-lock ready!

Name	Link
🔨 Latest commit	f753f705f38f8166e2dab9365ed5d87d0b90341d
🔍 Latest deploy log	https://app.netlify.com/sites/conda-lock/deploys/67b49d574f0814000842fcdc
😎 Deploy Preview	https://deploy-preview-775--conda-lock.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[maresb]

Hi @qmarcou, thanks so much for all your work on this. Sorry to take so long to respond, this ended up going a lot deeper than I expected.

I want to move things forward with deprecations, but as I've said I'm also concerned about breaking stuff, especially since the upcoming release is unfortunately going to be so big. The current logic involved is beyond my ability to reason about it, so the only way I could get a handle on it was to test all 48 possible combinations of relevant CLI arguments in https://github.com/conda/conda-lock/pull/778.

I've extended your work a bit, and cherry-picked the tests in https://github.com/qmarcou/conda-lock/pull/2. I would like to know what you think.

[qmarcou]

Hi @maresb , Apologies I have been busy and slacking on this. So in the end you favored a soft deprecation over the strict one you initially mentioned in #641?

From the user perspective, I think we should strive to make it as easy as possible to migrate from breaking changes. For example, I like the idea of deprecating an argument and failing with an error of how to switch to its direct replacement argument. If someone is maintaining some workflow, and we need to break it, then I'd like for them to have a 5-minute fix.

Thank you so much for your help with setting up CLI tests for all the optional dependencies switches. In the end did it help you figure out the current and desired default behavior for the lock and install commands?

[maresb]

Thanks so much @qmarcou for coming back to this, I really appreciate it!

I think I've decided on a hard deprecation, but with a flag that can be used as an escape hatch to restore the previous behavior. (I have some uncommitted changes where I think I've correctly replicated the previous behavior.)

Regarding the desired defaults, that's beyond my horizon at the moment. I need to focus fully on releasing conda-lock v3 and not breaking stuff. There's a lot in my head about potential failure modes between mamba v1 and v2, and I still need to make some changes to the test suite.

Once v3 is out (and assuming I'm not inundated with bug reports) then we can immediately figure out the desired default behavior. And now that you know my priorities (simple and clear migration path, and preferring "category" terminology to "extras"), you'll probably be able to figure out the correct solution and let me know once I'm ready. :smile:

[maresb]

I want to get v3 out tonight, so I'm going to let this slip. Sorry. :disappointed:

I plan to release much more frequently in the future, so I don't expect it to be such a big deal to get this in. I sincerely do value your contribution and feedback.

[qmarcou]

No worries, and congratulations for getting v3 out! Apologies I have been quite busy lately, and I wasn't sure whether you were waiting for action on my part before merging https://github.com/qmarcou/conda-lock/pull/2 in this current PR. I have just unlocked the workflow runs, and I could chnage the UserWarning to FutureWarning and we should be good to go?

[maresb]

Thanks @qmarcou!

Supposing we fix the warning and merge my PR, there are still two things on my mind:

1. Should we also merge #778?
2. I think my PR was triggering some spurious deprecation warnings when running without any arguments, so I think my detection for the distinction between omitted flags and explicitly-specified default flags may still be broken.

[qmarcou]

I think it would be good to also merge #778 , the code is well centralized and easy to remove if you decide to completely drop "--dev-dependency" support one day.

Regarding your second point, I did not have time to look into details, but could the new UserWarning raised by the deprecation be the cause of this discrepancy of the expected number of warnings? Though this should not happen when running without any argument.

I have added some comments to your proposed changes, but I may be a bit lost into the changes and their scope, they may be irrelevant (sorry for wasting your time in that case)