Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Tue, Jul 5, 2016 at 5:52 AM, Tomas Orsava  wrote:
>
>
> Oh! In that case, the documentation could be improved. :)
> Have you tested it? Is it reliable?
>

It worked well enough for me when I was doing the testing and
development for getting it upstream. A variant of it also worked for
years in Mageia.

> And also, there have been some concerns about opting out:
> Can the packager opt out of the dependency generator? There are cases where
> that might be necessary.

That's up to you. You'll need to set up the fileattr stuff so that
it's possible to revert back to the simpler dep generator whenever a
packager wants to go that route. I'm fairly certain it's possible,
though.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

On 07/04/2016 02:43 PM, Neal Gompa wrote:

On Mon, Jul 4, 2016 at 7:43 AM, Tomas Orsava  wrote:

Hi!

We have just removed the dependency generator from the proposal [0], see
diff [1].

The implementation of it (backported from RPM upstream) is significantly
lacking: Python dependencies are most usually found in setup.py and
requirements.txt files, whereas the dependency generator only takes
dependencies from the .dist-info or .egg-info files. There, the requirements
are often not listed at all, or if so, the listing can be incomplete.

Such behavior, I believe, would serve only to confuse packagers due to it's
highly unintuitive nature. It could be explained in the packaging
guidelines, but would add a lot of complexity without adding significant
(and consistent) benefits.

Therefore the dependency generator will not be turned on, and was removed
from the Fedora Change proposal.

Err, the reason it takes it from that information is because
requirements information is recorded in there during the %pyX_install
phase. It's exactly the same information. Today, most Python programs'
setup.py read the requirements.txt and record it in the info files
during install. It's more reliable that way because then it doesn't
have to figure out whether the requirements are in a requirements.txt
file, the setup.py file, or somewhere else. It's a consistent
location, and it eliminates test dependencies from being written in as
runtime ones.

Oh! In that case, the documentation could be improved. :)
Have you tested it? Is it reliable?

And also, there have been some concerns about opting out:
Can the packager opt out of the dependency generator? There are cases 
where that might be necessary.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Mon, Jul 4, 2016 at 7:43 AM, Tomas Orsava  wrote:
> Hi!
>
> We have just removed the dependency generator from the proposal [0], see
> diff [1].
>
> The implementation of it (backported from RPM upstream) is significantly
> lacking: Python dependencies are most usually found in setup.py and
> requirements.txt files, whereas the dependency generator only takes
> dependencies from the .dist-info or .egg-info files. There, the requirements
> are often not listed at all, or if so, the listing can be incomplete.
>
> Such behavior, I believe, would serve only to confuse packagers due to it's
> highly unintuitive nature. It could be explained in the packaging
> guidelines, but would add a lot of complexity without adding significant
> (and consistent) benefits.
>
> Therefore the dependency generator will not be turned on, and was removed
> from the Fedora Change proposal.

Err, the reason it takes it from that information is because
requirements information is recorded in there during the %pyX_install
phase. It's exactly the same information. Today, most Python programs'
setup.py read the requirements.txt and record it in the info files
during install. It's more reliable that way because then it doesn't
have to figure out whether the requirements are in a requirements.txt
file, the setup.py file, or somewhere else. It's a consistent
location, and it eliminates test dependencies from being written in as
runtime ones.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Hi!

We have just removed the dependency generator from the proposal [0], see 
diff [1].


The implementation of it (backported from RPM upstream) is significantly 
lacking: Python dependencies are most usually found in setup.py and 
requirements.txt files, whereas the dependency generator only takes 
dependencies from the .dist-info or .egg-info files. There, the 
requirements are often not listed at all, or if so, the listing can be 
incomplete.


Such behavior, I believe, would serve only to confuse packagers due to 
it's highly unintuitive nature. It could be explained in the packaging 
guidelines, but would add a lot of complexity without adding significant 
(and consistent) benefits.


Therefore the dependency generator will not be turned on, and was 
removed from the Fedora Change proposal.


[0] 
https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages
[1] 
https://fedoraproject.org/w/index.php?title=Changes%2FAutomatic_Provides_for_Python_RPM_Packages=461233=461232


Tomas Orsava


On 06/30/2016 02:20 PM, Jaroslav Reznik wrote:

= Proposed System Wide Change: Automatic Provides for Python RPM Packages =
https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages

Change owner(s):
* Tomas Orsava 
* Miro Hroncok 
* Email: python-ma...@redhat.com

Upon building Python packages containing packaging metadata, RPM will
automatically detect the standardized name of the software (i.e. dist name,
name on PyPI) in the canonical format [1] and create a virtual Provides tag
with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
version. RPM may also detect dependencies of the software from the metadata
and automatically require them using the same syntax.

== Detailed Description ==
If during the building of a Python package RPM encounters .egg-info, .egg-link
or .dist-info files (provided in Python Wheels and Eggs), it will read the
standardized name of the software (i.e. dist name, name on PyPI) in the
canonical format and create a virtual Provides tag with the value
pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
the canonical format can differ slightly from the name displayed, for example,
on PyPI.[1]

RPM will also detect dependencies of the software from the aforementioned
metadata files and automatically require them using the format
pythonX.Ydist(). However, because these files don't always contain the full
list of requirements (which are either in setup.py or requirements.txt), the
dependency generator will not be conclusive.

All Python packages will need to be rebuilt so that the virtual Provides tags
are generated and can be used by users, scripts and the requires generator.

== Scope ==
* Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
Python

* Maintainers of the RPM package: Backport the functionality from upsteram to
Fedora. — Already done thanks to Florian Festi [2]

* Release engineering: Targeted rebuild of Python packages. Ticket [3].

* List of deliverables: All Fedora deliverables will be affected, but only in
a very minor way that in no way jeopardizes their delivery.

* Policies and guidelines: Fedora Packaging Guidelines for Python need to be
updated after the implementation so users know how to take advantage of the
change.

* Trademark approval: Not needed for this Change

[1] https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Also, hasn't this been already discussed on the python-devel Fedora 
mailing list?


https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/3VYLAL22YPA7BSRTMRGAIAXKHXRFRGBF/


On 07/02/2016 12:13 PM, Tomas Orsava wrote:

- Original Message -

So, the "problem" with --majorver-provides occurs when either of the
two conditions are true:

* There's no dependency on a specific version of the Python ABI
("python(abi) = X.Y") in the modules
* There's more than one package providing a python implementation per
major version. (i.e. a package providing "python(abi) = 3.4" and
"python(abi) = 3.5")

In either case, you wind up in a scenario where it's possible to BR a
module that would be mismatched to the Python implementation. That is,
the module would be installed in a path that doesn't match the Python
implementation. Thus, the package would be effectively broken, since
it won't work.

Yes, that's exactly what we were trying to avoid.


However, in Mageia (which is where a variant of this dependency
generator is already used), we've never had this problem because
there's a dependency that forces it to match to the proper Python
implementation (Requires on "python(abi) = X.Y").

How does this work exactly? And could it be implemented for Fedora (within the 
scope of this change)?


And this generator has an additional protection (that doesn't exist in
the Mageia one) in that generated requires use
"pythonX.Ydist(CANONICAL_NAME)" no matter what.

True, but if then one BuildRequires: pythonXdist(M) is there a way to set which 
minor stack should be chosen?
I.e. can we set which Minor stack would be the default per the given Major 
version?


As for the interpreter running the dependency generator, it defaults
to whatever /usr/bin/python is, unless you override it.

I'm not sure I understand. And how does it work with Python 3?


--
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

- Original Message -
> So, the "problem" with --majorver-provides occurs when either of the
> two conditions are true:
> 
> * There's no dependency on a specific version of the Python ABI
> ("python(abi) = X.Y") in the modules
> * There's more than one package providing a python implementation per
> major version. (i.e. a package providing "python(abi) = 3.4" and
> "python(abi) = 3.5")
> 
> In either case, you wind up in a scenario where it's possible to BR a
> module that would be mismatched to the Python implementation. That is,
> the module would be installed in a path that doesn't match the Python
> implementation. Thus, the package would be effectively broken, since
> it won't work.

Yes, that's exactly what we were trying to avoid.

> 
> However, in Mageia (which is where a variant of this dependency
> generator is already used), we've never had this problem because
> there's a dependency that forces it to match to the proper Python
> implementation (Requires on "python(abi) = X.Y").

How does this work exactly? And could it be implemented for Fedora (within the 
scope of this change)?

> 
> And this generator has an additional protection (that doesn't exist in
> the Mageia one) in that generated requires use
> "pythonX.Ydist(CANONICAL_NAME)" no matter what.

True, but if then one BuildRequires: pythonXdist(M) is there a way to set which 
minor stack should be chosen?
I.e. can we set which Minor stack would be the default per the given Major 
version?

> 
> As for the interpreter running the dependency generator, it defaults
> to whatever /usr/bin/python is, unless you override it.

I'm not sure I understand. And how does it work with Python 3?

> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 3:58 PM, Tomas Orsava  wrote:
> Oh, sorry, I didn't look at the user name :)
>
> Could you please expand on what you have written here?
> I'm not sure I follow you entirely.

So, the "problem" with --majorver-provides occurs when either of the
two conditions are true:

* There's no dependency on a specific version of the Python ABI
("python(abi) = X.Y") in the modules
* There's more than one package providing a python implementation per
major version. (i.e. a package providing "python(abi) = 3.4" and
"python(abi) = 3.5")

In either case, you wind up in a scenario where it's possible to BR a
module that would be mismatched to the Python implementation. That is,
the module would be installed in a path that doesn't match the Python
implementation. Thus, the package would be effectively broken, since
it won't work.

However, in Mageia (which is where a variant of this dependency
generator is already used), we've never had this problem because
there's a dependency that forces it to match to the proper Python
implementation (Requires on "python(abi) = X.Y").

And this generator has an additional protection (that doesn't exist in
the Mageia one) in that generated requires use
"pythonX.Ydist(CANONICAL_NAME)" no matter what.

As for the interpreter running the dependency generator, it defaults
to whatever /usr/bin/python is, unless you override it.

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Oh, sorry, I didn't look at the user name :)

Could you please expand on what you have written here?
I'm not sure I follow you entirely.

- Original Message -
From: "Neal Gompa" <ngomp...@gmail.com>
To: "Development discussions related to Fedora" <devel@lists.fedoraproject.org>
Sent: Friday, July 1, 2016 5:43:46 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava <tors...@redhat.com> wrote:
> I'm sorry, I could have expanded on it.
>
> The difference is that if we enable --majorver-provides than there's no way
> we can ship more than one Minor version per a Major version [0].
>
> With macros, however, we have no problem shipping two minor versions, and
> the macros will continue to work, pointing to the one we treat as the
> main/default one. We can then also create macros for the additional minor
> version as well.
>
>
> [0] "The option '--majorver-provides' is intended for use
> if only one Python stack per major version will be
> available at a given time, as unexpected results may
> occur if there are multiple independent Python stacks
> per major version available." [1]
>

Yes, I wrote that comment.

The "unexpected" behavior in question is that if you have more than
one stack and you don't have some other constraint, the depsolver
could consider it an equal provider and install the wrong version of
the module for the version of python you want to use to build your
software/package. IMO, if the "python(abi)" requirement is matched
everywhere, it should function no differently than how it does today
when we do builds/rebuilds from one python version to the next. It's
probably worth testing to be sure, though...

The generated dependencies will all be major+minor specific, though.

You'll also probably want to enforce that the dep generator uses
python3 (as I did in my backport testing package[1]), since it uses
the unversioned python shebang by default.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava  wrote:
> I'm sorry, I could have expanded on it.
>
> The difference is that if we enable --majorver-provides than there's no way
> we can ship more than one Minor version per a Major version [0].
>
> With macros, however, we have no problem shipping two minor versions, and
> the macros will continue to work, pointing to the one we treat as the
> main/default one. We can then also create macros for the additional minor
> version as well.
>
>
> [0] "The option '--majorver-provides' is intended for use
> if only one Python stack per major version will be
> available at a given time, as unexpected results may
> occur if there are multiple independent Python stacks
> per major version available." [1]
>

Yes, I wrote that comment.

The "unexpected" behavior in question is that if you have more than
one stack and you don't have some other constraint, the depsolver
could consider it an equal provider and install the wrong version of
the module for the version of python you want to use to build your
software/package. IMO, if the "python(abi)" requirement is matched
everywhere, it should function no differently than how it does today
when we do builds/rebuilds from one python version to the next. It's
probably worth testing to be sure, though...

The generated dependencies will all be major+minor specific, though.

You'll also probably want to enforce that the dep generator uses
python3 (as I did in my backport testing package[1]), since it uses
the unversioned python shebang by default.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

I'm sorry, I could have expanded on it.

The difference is that if we enable --majorver-provides than there's no 
way we can ship more than one Minor version per a Major version [0].


With macros, however, we have no problem shipping two minor versions, 
and the macros will continue to work, pointing to the one we treat as 
the main/default one. We can then also create macros for the additional 
minor version as well.



[0] "The option '--majorver-provides' is intended for use
if only one Python stack per major version will be
available at a given time, as unexpected results may
occur if there are multiple independent Python stacks
per major version available." [1]

[1] 
https://github.com/rpm-software-management/rpm/commit/29abb07fbf6b9ea255bd26e492c104eac8d2370f


On 07/01/2016 02:23 PM, Neal Gompa wrote:

On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava  wrote:

Hi Neal!

I believe you will be able to use a macro for that so that dependencies are not 
tied to specific minor versions. I.e. something like:

(Build)Requires: python%{python3_version}dist(somemodule)

Of course that isn't very neat, so maybe 2 macros could be provided that would 
work thus:

(Build)Requires: %python2dist somemodule
(Build)Requires: %python3dist somemodule

That would solve the issue but still allow Fedora to possibly ship 2 different 
minor versions of Python 3 for example.


What makes that different from just enabling the --majorver-provides
and allowing people to use "python3dist(somemodule)" or
"python2dist(somemodule)"?

That said, it's not out of the question to be able to work that way,
as Ruby works similarly in openSUSE (since their system allows them to
support more than one version of ruby in parallel if they want) and
libraries work that way in Mageia.



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Hi Jason!

Ticket created: https://fedorahosted.org/fpc/ticket/635

Tomas

- Original Message -
From: "Jason L Tibbitts III" <ti...@math.uh.edu>
To: devel@lists.fedoraproject.org
Sent: Thursday, June 30, 2016 6:33:48 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

>>>>> "JR" == Jaroslav Reznik <jrez...@redhat.com> writes:

JR> * Proposal owners: Prepare a draft for the Fedora Packaging
JR>   Guidelines for Python

Please open a ticket with FPC sooner rather than later, even if the
draft isn't ready/started.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava  wrote:
> Hi Neal!
>
> I believe you will be able to use a macro for that so that dependencies are 
> not tied to specific minor versions. I.e. something like:
>
> (Build)Requires: python%{python3_version}dist(somemodule)
>
> Of course that isn't very neat, so maybe 2 macros could be provided that 
> would work thus:
>
> (Build)Requires: %python2dist somemodule
> (Build)Requires: %python3dist somemodule
>
> That would solve the issue but still allow Fedora to possibly ship 2 
> different minor versions of Python 3 for example.
>

What makes that different from just enabling the --majorver-provides
and allowing people to use "python3dist(somemodule)" or
"python2dist(somemodule)"?

That said, it's not out of the question to be able to work that way,
as Ruby works similarly in openSUSE (since their system allows them to
support more than one version of ruby in parallel if they want) and
libraries work that way in Mageia.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Tomas Orsava]

Hi Neal!

I believe you will be able to use a macro for that so that dependencies are not 
tied to specific minor versions. I.e. something like:

(Build)Requires: python%{python3_version}dist(somemodule)

Of course that isn't very neat, so maybe 2 macros could be provided that would 
work thus:

(Build)Requires: %python2dist somemodule
(Build)Requires: %python3dist somemodule

That would solve the issue but still allow Fedora to possibly ship 2 different 
minor versions of Python 3 for example.

Tomas

- Original Message -
From: "Neal Gompa" <ngomp...@gmail.com>
To: "Development discussions related to Fedora" <devel@lists.fedoraproject.org>
Sent: Thursday, June 30, 2016 2:31:51 PM
Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

On Thu, Jun 30, 2016 at 5:20 AM, Jaroslav Reznik <jrez...@redhat.com> wrote:
> = Proposed System Wide Change: Automatic Provides for Python RPM Packages =
> https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages
>
> Change owner(s):
> * Tomas Orsava <https://fedoraproject.org/wiki/User:Torsava>
> * Miro Hroncok <https://fedoraproject.org/wiki/User:Churchyard>
> * Email: python-ma...@redhat.com
>
> Upon building Python packages containing packaging metadata, RPM will
> automatically detect the standardized name of the software (i.e. dist name,
> name on PyPI) in the canonical format [1] and create a virtual Provides tag
> with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
> version. RPM may also detect dependencies of the software from the metadata
> and automatically require them using the same syntax.
>
> == Detailed Description ==
> If during the building of a Python package RPM encounters .egg-info, .egg-link
> or .dist-info files (provided in Python Wheels and Eggs), it will read the
> standardized name of the software (i.e. dist name, name on PyPI) in the
> canonical format and create a virtual Provides tag with the value
> pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
> the canonical format can differ slightly from the name displayed, for example,
> on PyPI.[1]
>
> RPM will also detect dependencies of the software from the aforementioned
> metadata files and automatically require them using the format
> pythonX.Ydist(). However, because these files don't always contain the full
> list of requirements (which are either in setup.py or requirements.txt), the
> dependency generator will not be conclusive.
>
> All Python packages will need to be rebuilt so that the virtual Provides tags
> are generated and can be used by users, scripts and the requires generator.
>
> == Scope ==
> * Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
> Python
>
> * Maintainers of the RPM package: Backport the functionality from upsteram to
> Fedora. — Already done thanks to Florian Festi [2]
>
> * Release engineering: Targeted rebuild of Python packages. Ticket [3].
>
> * List of deliverables: All Fedora deliverables will be affected, but only in
> a very minor way that in no way jeopardizes their delivery.
>
> * Policies and guidelines: Fedora Packaging Guidelines for Python need to be
> updated after the implementation so users know how to take advantage of the
> change.
>
> * Trademark approval: Not needed for this Change
>
> [1] https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0

It's awesome that this is finally going to make it into Fedora.
However, I strongly advise you have the --majorver-provides enabled
along with the default one, because that way, spec files can be
written in such a way that they can have BuildRequires that aren't
specific to a minor version of Python. The dependency generator
*always* uses the pythonX.Ydist(CANONICAL_NAME) format for generated
dependencies. The addition of pythonXdist(CANONICAL_NAME) Provides
just makes it easier to have BuildRequires for them so that mass
changes for spec files aren't required on every Y version bump.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Jason L Tibbitts III]

> "JR" == Jaroslav Reznik  writes:

JR> * Proposal owners: Prepare a draft for the Fedora Packaging
JR>   Guidelines for Python

Please open a ticket with FPC sooner rather than later, even if the
draft isn't ready/started.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Neal Gompa]

On Thu, Jun 30, 2016 at 5:20 AM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Automatic Provides for Python RPM Packages =
> https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages
>
> Change owner(s):
> * Tomas Orsava 
> * Miro Hroncok 
> * Email: python-ma...@redhat.com
>
> Upon building Python packages containing packaging metadata, RPM will
> automatically detect the standardized name of the software (i.e. dist name,
> name on PyPI) in the canonical format [1] and create a virtual Provides tag
> with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
> version. RPM may also detect dependencies of the software from the metadata
> and automatically require them using the same syntax.
>
> == Detailed Description ==
> If during the building of a Python package RPM encounters .egg-info, .egg-link
> or .dist-info files (provided in Python Wheels and Eggs), it will read the
> standardized name of the software (i.e. dist name, name on PyPI) in the
> canonical format and create a virtual Provides tag with the value
> pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
> the canonical format can differ slightly from the name displayed, for example,
> on PyPI.[1]
>
> RPM will also detect dependencies of the software from the aforementioned
> metadata files and automatically require them using the format
> pythonX.Ydist(). However, because these files don't always contain the full
> list of requirements (which are either in setup.py or requirements.txt), the
> dependency generator will not be conclusive.
>
> All Python packages will need to be rebuilt so that the virtual Provides tags
> are generated and can be used by users, scripts and the requires generator.
>
> == Scope ==
> * Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
> Python
>
> * Maintainers of the RPM package: Backport the functionality from upsteram to
> Fedora. — Already done thanks to Florian Festi [2]
>
> * Release engineering: Targeted rebuild of Python packages. Ticket [3].
>
> * List of deliverables: All Fedora deliverables will be affected, but only in
> a very minor way that in no way jeopardizes their delivery.
>
> * Policies and guidelines: Fedora Packaging Guidelines for Python need to be
> updated after the implementation so users know how to take advantage of the
> change.
>
> * Trademark approval: Not needed for this Change
>
> [1] https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0

It's awesome that this is finally going to make it into Fedora.
However, I strongly advise you have the --majorver-provides enabled
along with the default one, because that way, spec files can be
written in such a way that they can have BuildRequires that aren't
specific to a minor version of Python. The dependency generator
*always* uses the pythonX.Ydist(CANONICAL_NAME) format for generated
dependencies. The addition of pythonXdist(CANONICAL_NAME) Provides
just makes it easier to have BuildRequires for them so that mass
changes for spec files aren't required on every Y version bump.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Jaroslav Reznik]

On Thu, Jun 30, 2016 at 2:20 PM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Automatic Provides for Python RPM Packages =
> https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages
>
> Change owner(s):
> * Tomas Orsava 
> * Miro Hroncok 
> * Email: python-ma...@redhat.com
>
> Upon building Python packages containing packaging metadata, RPM will
> automatically detect the standardized name of the software (i.e. dist name,
> name on PyPI) in the canonical format [1] and create a virtual Provides tag
> with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
> version. RPM may also detect dependencies of the software from the metadata
> and automatically require them using the same syntax.
>
> == Detailed Description ==
> If during the building of a Python package RPM encounters .egg-info, .egg-link
> or .dist-info files (provided in Python Wheels and Eggs), it will read the
> standardized name of the software (i.e. dist name, name on PyPI) in the
> canonical format and create a virtual Provides tag with the value
> pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
> the canonical format can differ slightly from the name displayed, for example,
> on PyPI.[1]
>
> RPM will also detect dependencies of the software from the aforementioned
> metadata files and automatically require them using the format
> pythonX.Ydist(). However, because these files don't always contain the full
> list of requirements (which are either in setup.py or requirements.txt), the
> dependency generator will not be conclusive.
>
> All Python packages will need to be rebuilt so that the virtual Provides tags
> are generated and can be used by users, scripts and the requires generator.
>
> == Scope ==
> * Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
> Python
>
> * Maintainers of the RPM package: Backport the functionality from upsteram to
> Fedora. — Already done thanks to Florian Festi [2]
>
> * Release engineering: Targeted rebuild of Python packages. Ticket [3].
>
> * List of deliverables: All Fedora deliverables will be affected, but only in
> a very minor way that in no way jeopardizes their delivery.
>
> * Policies and guidelines: Fedora Packaging Guidelines for Python need to be
> updated after the implementation so users know how to take advantage of the
> change.
>
> * Trademark approval: Not needed for this Change
>
> [1] https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0

And two missing links :)

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1340885
[3] https://fedorahosted.org/rel-eng/ticket/6432

Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org