[CEP 26] Identifying Packages and Channels in the conda Ecosystem #116
Conversation
beckermr
left a comment
beckermr
left a comment
There was a problem hiding this comment.
A backwards compatibility section needs to be added with information pulled from the OCI CEP.
beckermr
left a comment
beckermr
left a comment
There was a problem hiding this comment.
To be honest, I'd leave allowed versions out of this CEP all together. That topic will require a significant amount of work that will block the rest of these items which are basically good to go.
|
I wonder if we should introduce maximum lengths across all categories, so we don't end up with something stupid like a package name of 50K characters. |
|
A maximum of 128 seems good to me. |
Co-authored-by: Matthew R. Becker <[email protected]>
Co-authored-by: Cheng H. Lee <[email protected]>
jaimergp
changed the title
Co-authored-by: Matthew R. Becker <[email protected]>
Co-authored-by: Matthew R. Becker <[email protected]>
Co-authored-by: jaimergp <[email protected]>
|
Love it, thanks @beckermr |
|
Hello @conda/steering-council. Requesting a vote for this CEP. This vote falls under the "Enhancement Proposal Approval" policy of the conda governance policy, It needs 60% of the Steering Council to vote To vote, please use the following form to vote. If you have questions concerning the proposal, you may also leave a comment or code review. This vote will end on 2025-05-06, End of Day, Anywhere on Earth (AoE). @xhochy (Uwe Korn)
@CJ-Wright (Christopher J. 'CJ' Wright)
@mariusvniekerk (Marius van Niekerk)
@chenghlee (Cheng H. Lee)
@ocefpaf (Filipe Fernandes)
@marcelotrevisani (Marcelo Duarte Trevisani)
@msarahan (Michael Sarahan)
@mbargull (Marcel Bargull)
@jakirkham (John Kirkham)
@jezdez (Jannis Leidel)
@wolfv (Wolf Vollprecht)
@jaimergp (Jaime Rodríguez-Guerra)
@baszalmstra (Bas Zalmstra)
@beckermr (Matthew R. Becker)
@Hind-M (Hind Montassif)
@trallard (Tania Allard)
|
|
@CJ-Wright, @mariusvniekerk, @ocefpaf, @marcelotrevisani, @msarahan, @mbargull, @jakirkham, @jezdez, @baszalmstra: your mid-period reminder to vote, thanks! |
mbargull
left a comment
mbargull
left a comment
There was a problem hiding this comment.
I'm very thankful that you continue to work on/write up how specification-like documents for all these previously only "implementation-defined" (and thus bound to be diverging) workings.
I vote to accept this proposal since it is a very good starting point to align implementations in package managers as well as distribution tools overall.
Unfortunately I wasn't able to take part in the discussion beforehand (but expect to be able to in the near future), so I apologize to not have given input before.
There are certain points (channel name/label definition, maximum length of package name/version/buildstring, etc.) that are either different from current definitions or possibly too restrictive.
E.g., maximum component lengths are worded with MUST NOT exceed even though we have existing cases that do exceed the given limits already -- hence it might make sense to have higher MUST NOT exceed limits and possibly have the current lower limits declared as SHOULD NOT exceed.
In my eyes in makes sense to declare this proposal as "provisional" since adjusting implementation to be "compliant to CEP XXXX" could be counter productive until those points have been worked on in later refinements to this proposal.
| Distributable package names MUST match the following case-insensitive regex: | ||
| `^(([a-z0-9])|([a-z0-9_](?!_)))[._-]?([a-z0-9]+(\.|-|_|$))*$`. | ||
|
|
||
| Virtual package names MUST follow this regex: `^__[a-z0-9][._-]?([a-z0-9]+(\.|-|_|$))*$`. |
There was a problem hiding this comment.
I realize it's more of a "taste" thing, but the expressions might be easier to grasp without negative lookaheads, e.g.,
| Distributable package names MUST match the following case-insensitive regex: | |
| `^(([a-z0-9])|([a-z0-9_](?!_)))[._-]?([a-z0-9]+(\.|-|_|$))*$`. | |
| Virtual package names MUST follow this regex: `^__[a-z0-9][._-]?([a-z0-9]+(\.|-|_|$))*$`. | |
| Distributable package names MUST match the following case-insensitive regex: | |
| `^[._-]?([a-z0-9][._-]?)+$`. | |
| Virtual package names MUST follow this regex: `^__([a-z0-9][._-]?)+$`. |
There was a problem hiding this comment.
We want to disallow consecutive separators in the string, like numpy--base or matplotlib.-extra.
There was a problem hiding this comment.
Maybe like this?
^([a-z0-9]+|(_[a-z0-9]+))[._-]?([a-z0-9]+(\.|-|_|$))*$There was a problem hiding this comment.
I've found these things are tricky and the negative lookahead was all that I could get to work when I was working on similar things.
| Artifact extensions MUST only consist of lowercase ASCII letters, numbers and periods. They must | ||
| start and end with a letter or a number. They MUST NOT include two consecutive periods. They MUST | ||
| match this regex `^[a-z0-9](\.?[a-z0-9])*$`. |
There was a problem hiding this comment.
It is also common include the separating period as part of the file extension.
In our case it'd be fine to exclude it since we always expect a non-empty suffix after the period.
Including it might avoid ambiguities, though, e.g., "conda supports .conda files since version 4.7".
| start and end with a letter or a number. They MUST NOT include two consecutive periods. They MUST | ||
| match this regex `^[a-z0-9](\.?[a-z0-9])*$`. | ||
|
|
||
| The maximum length of a file extension MUST NOT exceed 16 characters. |
There was a problem hiding this comment.
| The maximum length of a file extension MUST NOT exceed 16 characters. | |
| The maximum length of an artifact extension MUST NOT exceed 16 characters. |
for consistency.
| For convenience, the channel _name_ is defined as the concatenation of `scheme`, `authority` and | ||
| `path` components of a channel URL. At least one of `authority` or `path` SHOULD be present. In | ||
| their absence, the channel name MUST be considered empty, regardless the scheme. Empty channel | ||
| names SHOULD NOT be used. |
There was a problem hiding this comment.
This deviates, e.g., from how conda's implementation uses (or at least used to use in the past) the term name.
E.g., for conda.models.channel.Channel a https://conda.anaconda.org/conda-forge/label/main would (using the default channel alias) yield conda-forge/label/main as the Channel.name.
One reason for this that conda itself has (had?) no concept of "label" at all but only distribution related tooling (e.g., conda.anaconda.org's server or tools like anaconda-client or conda-smithy) use that concept.
This is not to say it does not make sense to include the "label" concept at all -- it's certainly good to have this distribution-specific part specified since it's widely used, e.g., in conda-forge.
We should just be careful to align meanings of channel names, labels, etc. in specs and tooling (which this proposal is/can be used to get it going, of course).
| The label `nolabel` is reserved and MUST only be used for conda packages which have no other | ||
| labels. In other words, in the space of labels, the empty set is represented by the labels | ||
| `nolabel`. |
There was a problem hiding this comment.
I'm not aware of nolabel reservation -- is this an existing thing for conda.anaconda.org or is it something to do with the OCI work mentioned in the comments?
|
The vote is closed, and we have the following result:
Yes votes (12 / 100%):
No votes (0 / 0.00%). Abstain votes (0 / 0.00%). Not voted (4): Invalid votes (0). 12/16 votes = 75% meets the minimum quorum. As per the governance, the @conda/steering-council has approved this CEP. |
jaimergp
changed the title
|
Thank you @mbargull (and welcome back!). I'll take a note of your feedback in a new issue so we can address this in a future revision. |
|
I want to add in relation to @mbargull's comments that
|
|
Also this CEP is not provisional in any sense. It has passed and documents conda standards until a future CEP changes them. |
9 participants
Rendered CEP
Comes from #115 (comment).
Addresses the long needed standardization of package names and channel names.
I took @beckermr's regexes and added some more details and structure. Very open to feedback in how descriptive vs prescriptive we should get. So far, only trying to describe roughly what we have in
conda. I'd like to know more about how this is handled inrattler. cc @baszalmstra @wolfv