#61810 closed defect (fixed)
certbot and subports set dependencies incorrectly with most variants
Reported by: | jmroot (Joshua Root) | Owned by: | Schamschula (Marius Schamschula) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | certbot |
Description
Dependencies are being set before the variants are executed, which means python.version has a fixed value. E.g.
% port deps certbot +python38 Full Name: certbot @1.10.1_0+python38 Build Dependencies: py39-setuptools Library Dependencies: py39-acme, py39-configargparse, py39-configobj, py39-cryptography, py39-distro, py39-future, py39-google-api, py39-httplib2, py39-mock, py39-oauth2client, py39-openssl, py39-parsedatetime, py39-psutil, py39-pyrfc3339, py39-six, py39-tz, py39-zope-component, py39-zope-deferredimport, py39-zope-deprecation, py39-zope-hookable, python38
Change History (13)
comment:1 Changed 4 years ago by Schamschula (Marius Schamschula)
comment:2 follow-up: 4 Changed 4 years ago by Schamschula (Marius Schamschula)
PS: if the variants are not parsed before the dependents, no ${python.version}
would have been set.
comment:3 Changed 4 years ago by jmroot (Joshua Root)
Variant bodies are executed after the portfile is executed. You need to either set the dependencies inside the variants as well, or use variant_isset to set python.default_version before setting the dependencies.
comment:4 Changed 4 years ago by jmroot (Joshua Root)
Replying to Schamschula:
PS: if the variants are not parsed before the dependents, no
${python.version}
would have been set.
Correct, it is not set yet by the portfile, so it has its default value.
comment:5 Changed 4 years ago by jmroot (Joshua Root)
I can fix this for you as an example of how to do it, if you like.
comment:6 Changed 4 years ago by Schamschula (Marius Schamschula)
Please! There is obviously something I'm missing here.
I, and others, have used this code in a number of Python app Portfiles for quite a while w/o any apparent issues.
comment:7 Changed 4 years ago by jmroot (Joshua Root)
You wouldn't have seen any issues as long as the variant selected matched the default python version.
comment:8 Changed 4 years ago by Schamschula (Marius Schamschula)
Indeed! Until 3.9 came out recently, I was always building against the default version.
Setting the dependencies inside the variants is very clumsy: lots of redundant code. There must be a more elegant way to do this.
This makes Python app ports a pain as compared to Python libraries.
comment:9 Changed 4 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:10 Changed 4 years ago by Schamschula (Marius Schamschula)
Thanks, Joshua!
Time to use this elsewhere.
The opposite is true: The variant block precedes the dependency block.
Maybe, it isn't parsed that way? Or perhaps, there is something else going on?
However, I can reproduce the issue. Indeed, I see it in other Portfiles.