[Distutils] Re: Deal with pip setup.py name and rpm packaging
Petr, thank you for these clarifications. I'm new on this world, and
I'm a bit confusing.
Resuming, I have a SPEC file with
%{?python_enable_dependency_generator}
that force the Redis server replacement with the python redis client.
The problem, from what I can see, is that RPM package also include the
following Provides:
<%{name}> =
For this reason when I installed the package which requires
python3.Ydist(redis), the Redis server was "updated" (replaced) with
the python client Redis package.
I fixed this modifying the %{name} in SPEC file of the client Redis
package with something different from "redis". In this way I can still
use
%{?python_enable_dependency_generator}
in my SPEC package.
The automatic provides doc
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_python_provide_macro
doesn't seem to refer to that Provide value. It only talk about
python3.Ydist(CANONICAL_STANDARDIZED_NAME)
For the python3.Ydist(python-magic) there is no similar fix, because
there is an already existing python package with the same name. I
adjusted the Require version in my own package to deal with this.
Thank you for the hint on pyp2rpm, I agree that anyway bdist_rpm makes
a non-definitive SPEC file.
Finally I apologize for the wrong place where to ask help for this.
Thank you again for your help
Marco
Il giorno mer 15 gen 2020 alle ore 11:55 Petr Viktorin
ha scritto:
>
> On 2020-01-15 10:33, Marco Favero wrote:
> > Hello,
> >
> >recently I started to develop a tool in python.
> > I discovered pip and setuptool with setup.py. It's fantastic! I can provide
> > packaging to pypi and to rpm all in a row.
> > I follow these guidelines:
> > -
> > https://packaging.python.org/tutorials/packaging-projects/#generating-distribution-archives
> > - https://docs.python.org/3/distutils/builtdist.html?highlight=rpm
> > - https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
> >
> > With %{?python_enable_dependency_generator} the RPM provides the
> > dependecies itself. Fantastic!
> >
> > But how to force the developers to use consistent names? :D
> >
> > For instance these python-magic and redis client packages:
> >
> >https://pypi.org/project/python-magic
> >https://pypi.org/project/redis/
> >
> > use names which conflict with already existent rpm packages names. In
> > particular, "redis" in rpm is the name of the Redis server package! If I
> > make "bdist_rpm" of python Redis client and I "yum install" the package I
> > damage my system deleting the Redis server!
> > The Redis client developer says that he can't change the name because this
> > will break existent installations:
> > https://github.com/andymccurdy/redis-py/pull/385
> >
> > I think this is not a good situation. Python environment should help to
> > improve an "inconsistent" setup.
> >
> > As a result, I have to make bdist_rpm of the dependencies, then I have to
> > install the source rpm, change the name in SPEC file and rebuild the rpm
> > package. In my package I can't use %{?python_enable_dependency_generator},
> > because it uses the fault pypi names, I have to provide them myself. :(
> >
> > Thank you for reading this noise
> > Have a fantastic python day
>
> Hi!
> Guessing by the guideline you follow, you're packaging for Fedora. It
> would be best to use the python-de...@lists.fedoraproject.org mailing
> list for that.
>
> PyPI and distro repositories are different namespaces. They contain
> different packages (Python packages vs. distro-maintained ones in any
> language). They're governed by different people and different
> guidelines. The packages are often maintained by different people
> (developers vs. distro maintainers).
> It would be great if the names for similar things were similar across
> namespaces, but it's not feasible to always be in sync.
>
> To solve this issue, Fedora uses virtual provides. A RPM with a package
> from PyPI should provide:
>
> python3.7dist() =
>
> ... and any packages can depend on that. That's what the Python
> dependency generator uses; the names of RPMs are not relevant.
> For the name of the RPM, it's conventional to use "python3- PYPI>", but you can use something else to prevent conflicts.
>
> The bdist_rpm command is unlikely to be improved. It will give you a RPM
> that can probably be installed, but doesn't really conform to any distro
> guidelines. It's also part of setuptools, which is quite hard to work on
> and is being slowly deprecated.
>
> You could try pyp2rpm ( https://github.com/fedora-python/pyp2rpm ),
> which generates a spec file that you can then edit.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/WAXG5UJKDXGO46SJTOBXAGKXZIYZUXBA/
[Distutils] Re: Deal with pip setup.py name and rpm packaging
On 2020-01-15 10:33, Marco Favero wrote:
Hello,
recently I started to develop a tool in python.
I discovered pip and setuptool with setup.py. It's fantastic! I can provide
packaging to pypi and to rpm all in a row.
I follow these guidelines:
-
https://packaging.python.org/tutorials/packaging-projects/#generating-distribution-archives
- https://docs.python.org/3/distutils/builtdist.html?highlight=rpm
- https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
With %{?python_enable_dependency_generator} the RPM provides the dependecies
itself. Fantastic!
But how to force the developers to use consistent names? :D
For instance these python-magic and redis client packages:
https://pypi.org/project/python-magic
https://pypi.org/project/redis/
use names which conflict with already existent rpm packages names. In particular, "redis" in rpm is
the name of the Redis server package! If I make "bdist_rpm" of python Redis client and I "yum
install" the package I damage my system deleting the Redis server!
The Redis client developer says that he can't change the name because this will
break existent installations:
https://github.com/andymccurdy/redis-py/pull/385
I think this is not a good situation. Python environment should help to improve an
"inconsistent" setup.
As a result, I have to make bdist_rpm of the dependencies, then I have to
install the source rpm, change the name in SPEC file and rebuild the rpm
package. In my package I can't use %{?python_enable_dependency_generator},
because it uses the fault pypi names, I have to provide them myself. :(
Thank you for reading this noise
Have a fantastic python day
Hi!
Guessing by the guideline you follow, you're packaging for Fedora. It
would be best to use the python-de...@lists.fedoraproject.org mailing
list for that.
PyPI and distro repositories are different namespaces. They contain
different packages (Python packages vs. distro-maintained ones in any
language). They're governed by different people and different
guidelines. The packages are often maintained by different people
(developers vs. distro maintainers).
It would be great if the names for similar things were similar across
namespaces, but it's not feasible to always be in sync.
To solve this issue, Fedora uses virtual provides. A RPM with a package
from PyPI should provide:
python3.7dist() =
... and any packages can depend on that. That's what the Python
dependency generator uses; the names of RPMs are not relevant.
For the name of the RPM, it's conventional to use "python3-PYPI>", but you can use something else to prevent conflicts.
The bdist_rpm command is unlikely to be improved. It will give you a RPM
that can probably be installed, but doesn't really conform to any distro
guidelines. It's also part of setuptools, which is quite hard to work on
and is being slowly deprecated.
You could try pyp2rpm ( https://github.com/fedora-python/pyp2rpm ),
which generates a spec file that you can then edit.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/BAKFPGNGD3PUWK2SUS2MNAOMSEUI2N2L/
[Distutils] Deal with pip setup.py name and rpm packaging
Hello,
recently I started to develop a tool in python.
I discovered pip and setuptool with setup.py. It's fantastic! I can provide
packaging to pypi and to rpm all in a row.
I follow these guidelines:
-
https://packaging.python.org/tutorials/packaging-projects/#generating-distribution-archives
- https://docs.python.org/3/distutils/builtdist.html?highlight=rpm
- https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
With %{?python_enable_dependency_generator} the RPM provides the dependecies
itself. Fantastic!
But how to force the developers to use consistent names? :D
For instance these python-magic and redis client packages:
https://pypi.org/project/python-magic
https://pypi.org/project/redis/
use names which conflict with already existent rpm packages names. In
particular, "redis" in rpm is the name of the Redis server package! If I make
"bdist_rpm" of python Redis client and I "yum install" the package I damage my
system deleting the Redis server!
The Redis client developer says that he can't change the name because this will
break existent installations:
https://github.com/andymccurdy/redis-py/pull/385
I think this is not a good situation. Python environment should help to improve
an "inconsistent" setup.
As a result, I have to make bdist_rpm of the dependencies, then I have to
install the source rpm, change the name in SPEC file and rebuild the rpm
package. In my package I can't use %{?python_enable_dependency_generator},
because it uses the fault pypi names, I have to provide them myself. :(
Thank you for reading this noise
Have a fantastic python day
Marco
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/P6L55YQUGMZFO77JVAYM4ZIE3GFG6LTU/
[Distutils] Re: Packaging Summit 2020: Save the Date!
That opening definitely made me laugh. :) Thanks for the date confirmation, and for picking up the responsibility for putting this together Paul and Bernat! Best, Pradyun On Wed, Jan 15, 2020 at 7:06 AM Paul Ganssle wrote: > Greetings one and all! > > Each year millions of eyes around the world eagerly wait at their computer > with baited breath to learn the timing of the most fabulous, extravagant, > decadent and hyperbolically oversold event of the year: The Python > Packaging Summit. While most of the details aren't finalized (and in fact > basically no details are finalized), in the interest of giving those who > would like to attend a chance at some additional notice on their travel > plans, we have established that the date of the summit: *Thursday, 16 > April 2020* (the day before the first PyCon talk day). > > For the past two years we've unofficially held our mini-summit on the > first day of PyCon Sprints, but given that this summit is of particular > interest to maintainers - many of whom would like to spend the first day of > sprints actually sprinting - we have decided to run the summit on the > tutorials day parallel to the Education Summit. We have applied for a spot > in the Hatchery program, but even if we are not accepted as an official > PyCon evenat, we will make arrangements to run the summit off-site on that > day. > > For those unaware of the nature of the summit, you may want to pay > attention to the "hyperbolically oversold" portion of my description less > than the "decadent" and "extravagant" portions. The purpose of the summit > is to get a bunch of people interested in Python Packaging together to > discuss and coordinate on important topics in packaging and how we can move > them forward. If you are on the fence about joining and want to know more, > here are some detailed notes taken at the summit last year: > https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zDGj7g/edit#heading=h.7rw2gk16okic > > As I mentioned earlier, we have finalized essentially *no* details of > this summit other than the date. I do not know how many people will be able > to attend or by what mechanism we will prioritize attendance at the summit > if there is limited space. > > In the coming months please keep an eye out for: > >- Registration details (if such a thing is deemed necessary) >- A call for topic suggestions >- Voting on how to prioritize topic suggestions > > Looking forward to seeing you all there! > Paul > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/ZEZNY2MCUN3S3JGUFF6U6OWVEOKW2UAF/ > -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/WNBWSX7AYRPGA4RUBEULAXYKF4JAXYUG/
