Re: python3 entry_points console scripts packaging question
On Wed, Nov 27, 2019 at 05:11:37PM +0100, Dominique Martinet wrote:
> Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100:
...snip...
> > And in Fedora, when you ahve both of those, it also means that
> > /usr/bin/python3 is Python 3.8.
>
> Ok, I thought it was just much less likely but it would also fail on
> upgrade, good to know.
>
>
> > However, this might not be the case for EPELs.
>
> Yes, they have python36-setuptools and python34-setuptools at the same
> time right now, and the packages do not conflict in any way.
>
> > The easiest way to ensure a specific shebang is:
> >
> >%global __python3 /usr/bin/python%{python3_version}
>
> Thanks, I will add that for our EPEL builds only.
Just to note, the python34 stack in epel7 is the 'old' one.
Everyone should if at all possible use the 3.6 stack now.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3 entry_points console scripts packaging question
Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100:
> If I understand this properly, your package requires (in Fedora):
>
> - /usr/bin/python3
> - python3.8dist(setuptools)
Yes, on Fedora 31 the current requires for clustershell (to continue
with that example) contain these:
$ rpm -q --requires python3-clustershell
/usr/bin/python3
python(abi) = 3.7
python3-PyYAML
python3-setuptools
python3.7dist(pyyaml)
python3.7dist(setuptools)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
> And in Fedora, when you ahve both of those, it also means that
> /usr/bin/python3 is Python 3.8.
Ok, I thought it was just much less likely but it would also fail on
upgrade, good to know.
> However, this might not be the case for EPELs.
Yes, they have python36-setuptools and python34-setuptools at the same
time right now, and the packages do not conflict in any way.
> The easiest way to ensure a specific shebang is:
>
>%global __python3 /usr/bin/python%{python3_version}
Thanks, I will add that for our EPEL builds only.
--
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3 entry_points console scripts packaging question
On 27. 11. 19 16:20, Dominique Martinet wrote:
Hi,
Some context first, skip to the end if you want.
We have a few python packages at $work with setuptools entry_points
console scripts - basically setuptools creates a small python script for
you loading a module and calling the function you specified.
For example, clustershell here defines four commands (clubak cluset
clush and nodeset) here:
https://github.com/cea-hpc/clustershell/blob/master/setup.py#L57
Setuptool embeds whatever python command was executed for running
setup.py at the start of the script, so if the command used in the spec
file was %py3_install as per the guidelines or even %{__python3}
setup.py something, you will get a #!/usr/bin/python3 shebang in your
scripts.
On the other hand, the script depends on what just got installed in
/usr/lib/python3.x/site-packages, so if python3 gets a major upgrade and
the /usr/bin/python3 link changes, the script will stop working
complaining that whatever it tried to import does not exist, while in
reality everything is still there, works if you run it with the right
python version, and the rpm requires ensure this properly.
For packages in fedora this doesn't matter as much as there is a python
mass rebuild when this happens, but I'm not sure it happens with epel
version bump, and it certainly doesn't happen for our internal packages
(hence this message!)
Now for the big question, should we try using `python%{python3_version}`
or fixing the link in scripts somehow for our rpms ?
Can anyone think of a cleaner way?
Another idea that just came to mind would be to try to write in the spec
file that we require /usr/bin/python3 to point to a specific version, so
that at least it fails to upgrade, but that doesn't sound much better
and I wouldn't know how to do that anyway.
If I understand this properly, your package requires (in Fedora):
- /usr/bin/python3
- python3.8dist(setuptools)
And in Fedora, when you ahve both of those, it also means that /usr/bin/python3
is Python 3.8.
However, this might not be the case for EPELs. The easiest way to ensure a
specific shebang is:
%global __python3 /usr/bin/python%{python3_version}
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python3 entry_points console scripts packaging question
Hi,
Some context first, skip to the end if you want.
We have a few python packages at $work with setuptools entry_points
console scripts - basically setuptools creates a small python script for
you loading a module and calling the function you specified.
For example, clustershell here defines four commands (clubak cluset
clush and nodeset) here:
https://github.com/cea-hpc/clustershell/blob/master/setup.py#L57
Setuptool embeds whatever python command was executed for running
setup.py at the start of the script, so if the command used in the spec
file was %py3_install as per the guidelines or even %{__python3}
setup.py something, you will get a #!/usr/bin/python3 shebang in your
scripts.
On the other hand, the script depends on what just got installed in
/usr/lib/python3.x/site-packages, so if python3 gets a major upgrade and
the /usr/bin/python3 link changes, the script will stop working
complaining that whatever it tried to import does not exist, while in
reality everything is still there, works if you run it with the right
python version, and the rpm requires ensure this properly.
For packages in fedora this doesn't matter as much as there is a python
mass rebuild when this happens, but I'm not sure it happens with epel
version bump, and it certainly doesn't happen for our internal packages
(hence this message!)
Now for the big question, should we try using `python%{python3_version}`
or fixing the link in scripts somehow for our rpms ?
Can anyone think of a cleaner way?
Another idea that just came to mind would be to try to write in the spec
file that we require /usr/bin/python3 to point to a specific version, so
that at least it fails to upgrade, but that doesn't sound much better
and I wouldn't know how to do that anyway.
Thanks,
--
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
