rattler
rattler copied to clipboard
mamba-org
export `MatchSpec` in js-rattler
Checklist
- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate
What is the idea?
export MatchSpec to js-rattler so downstream npm users can parse an match spec string and extra info like channel, package name, version and etc.
Why is this needed?
This will help developer who want to add conda (environment.yaml) manager support to renovatebot
https://github.com/renovatebot/renovate/issues/2213
What should happen?
No response
Additional Context
I won't add conda manager support to renovatebot, so no rush. It's something nice to have, but currently won't block anything (IMO).
As we expand the scope of js-rattler this will definitely be part of it!
current MatchSpec maybe not very suitable for the use case of renovatebot...
for example:
from rattler import MatchSpec
print(MatchSpec("pytest ==3.1.2.*").version) # 3.1.2.*
print(MatchSpec("pytest >=3.1.2.*").version) # >=3.1.2
print(MatchSpec("foo=1.0=py27_0").version) # ==1.0
Looks like we have some kind of normalization here , I'm hoping to get ==3.1.2.* >=3.1.2.* =1.0 here, is it possible?
Mm no there is currently no way to get the original (ambiguous) spec.
Can you help me understand why that is important? Do you want to modify these as wel?
Mm no there is currently no way to get the original (ambiguous) spec.
Can you help me understand why that is important? Do you want to modify these as wel?
Yes, renovatebot will need to modify it. for example, when a new package is release, change from pytest ==3.1.2.* to pytest ==3.2.0, or change from pytest >=3.1.2.* to pytest >=3.2.0 based on different user config.
So it's important to get the raw value as-is. It will be possible to parse the whole MatchSpec and build a new one from parsed result, but that's normally not what user wants. You normally only want renovatebot update your version part.
A example with pep517:
I understand but the given spec is also ambiguous.
==3.4.* says
- exactly equal to
3.4.* - any version starting with
3.4
We interpret this simply as: any version starting with 3.4 .
So wouldnt replacing it with a non-ambiguous version specifier also be correct? Say 3.5.*
I understand but the given spec is also ambiguous.
==3.4.*says
- exactly equal to
3.4.*- any version starting with
3.4We interpret this simply as: any version starting with
3.4.So wouldnt replacing it with a non-ambiguous version specifier also be correct? Say
3.5.*
in any case renovate need to get raw value here, then it can do a replacement
The normalization works fine in manually editing case and works fine for a package manger to check if it match a version string, but not very ideal updating it programmably. This is kinda like json AST vs json object as python object. If you only want to read it, python object is fine. But if you want to do style preserving updating, you will need AST.
I understand it may be ambiguous ( it's actually a pep440 version spec), but even after we normalize it, we still need to replace old version spec with new version spec in MatchSpec string .
THis problem doesn't exist in pixi because in pixi.toml it's a single solo string not mixed with other string, but not in conda, and at here the normalizetion cause trouble.
Mm in that case we need an additional ast/cst style parser for matchspec I suppose.
Dont you also want to replace other parts of the matchspec as well during an update? I can imagine you might also want to update the build string/number if specified.
Mm in that case we need an additional ast/cst style parser for matchspec I suppose.
Dont you also want to replace other parts of the matchspec as well during an update? I can imagine you might also want to update the build string/number if specified.
that's maybe necessary， but need some new change in renovate 😂
I'm guessing we need to skip dep with build/build number for now in pixi