Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre-draft: A conda technical specification #22

Open
jaimergp opened this issue May 12, 2022 · 2 comments
Open

Pre-draft: A conda technical specification #22

jaimergp opened this issue May 12, 2022 · 2 comments

Comments

@jaimergp
Copy link
Contributor

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.

@jaimergp
Copy link
Contributor Author

jaimergp commented Nov 1, 2023

@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.

@chenghlee
Copy link

Did you know that you can have ❤️-1-0.conda?

Yes, I did. And you can conda create -n beep^G so the terminal constantly beeps at you whenever you have that environment activated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants