You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on conda-libmamba-solver, we tried hard to maintain backwards compatibility with the classic solver, but getting 100% the same behaviour proved to be tricky. One of the reasons is that it's difficult to separate what is supposed to be a "expected behaviour" from an "implementation detail".
There are some foundational principles for that behaviour that can be found across comments, issues, PRs and other contextual metadata, but there's no detailed specification for what should happen under X circumstances.
I'd like to start a discussion around the need of standardising the behaviour of conda as a CLI tool and the outcomes of a number of actions. Such a document should allow us to clearly answer to questions like:
Given a fresh Python 3.7 environment, should conda install numpy=*=*py39* update the Python version implicitly or should the user also add python=3.9 to the list of specs?
Spec'ing these things out would allow the community to have a wider view of conda actually does (and you'd be surprised to learn how many implicit variables are part of that process), and what future iterations of the ecosystem should do instead. For example, I'd like to see how feasible is to steer the logic towards more explicit behaviour.
Topics to discuss include:
Scope of the spec: which parts of conda need standardisation?
Programmatic enforcement: can we create a tool agnostic test suite?
Command-line interfaces: do we want to have a single CLI standard across tools?
This doesn't mean we need to tackle all of those issues in a single CEP. Actually, using several could be beneficial.
The text was updated successfully, but these errors were encountered:
@chenghlee and others were discussing the issue with allowed package names in conda. Did you know that you can have ❤️-1-0.conda? It'd be good to have a standard for this where we say that a package name can only use [a-zA-Z0-9\-_\.\+] or similarly constrained subsets of ASCII.
While working on
conda-libmamba-solver
, we tried hard to maintain backwards compatibility with the classic solver, but getting 100% the same behaviour proved to be tricky. One of the reasons is that it's difficult to separate what is supposed to be a "expected behaviour" from an "implementation detail".There are some foundational principles for that behaviour that can be found across comments, issues, PRs and other contextual metadata, but there's no detailed specification for what should happen under X circumstances.
I'd like to start a discussion around the need of standardising the behaviour of
conda
as a CLI tool and the outcomes of a number of actions. Such a document should allow us to clearly answer to questions like:Spec'ing these things out would allow the community to have a wider view of
conda
actually does (and you'd be surprised to learn how many implicit variables are part of that process), and what future iterations of the ecosystem should do instead. For example, I'd like to see how feasible is to steer the logic towards more explicit behaviour.Topics to discuss include:
This doesn't mean we need to tackle all of those issues in a single CEP. Actually, using several could be beneficial.
The text was updated successfully, but these errors were encountered: