Bug 531648 - Review Request: python3-setuptools - Easily build and distribute Python 3 packages
Review Request: python3-setuptools - Easily build and distribute Python 3 pac...
Status: CLOSED DUPLICATE of bug 531895
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On: 526126 554799
Blocks: Python3F13
  Show dependency treegraph
 
Reported: 2009-10-28 20:40 EDT by Dave Malcolm
Modified: 2010-01-31 20:43 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-31 20:43:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Malcolm 2009-10-28 20:40:00 EDT
Spec URL: http://dmalcolm.fedorapeople.org/python3-packaging/python3-setuptools/python3-setuptools.spec
SRPM URL: http://dmalcolm.fedorapeople.org/python3-packaging/python3-setuptools/python3-setuptools-0.6.6-2.fc13.src.rpm

Description:
(you can see the formal description in the specfile).

I hope to build a parallel-installable python 3 stack for Fedora 13; see: https://fedoraproject.org/wiki/Features/Python3F13

This is the first add-on to python 3 that I've submitted for package review; as one of the lowest-level components of a python stack this is useful for building other python modules for python 3.

It isn't yet clear to me what the packaging guidelines for this situation should be, so this should be an interesting review!

One guideline we need that this package currently breaks is that it needs to be fully-parallel installable with the python- version of the code.  I suspect there's a problem with the -devel subpackage here, with both packages wanting to own "/usr/bin/easy_install".

However, I thought it was worth posting here for review to get more feedback on whether this is a sane approach, or if there are better ways of packaging this.

I took the python-setuptools srpm and adjusted it to use python3 rather than python (i.e 3.1 vs 2.6)

A diff between the specfiles can be seen here:
http://dmalcolm.fedorapeople.org/python3-packaging/python3-setuptools/from-python-setuptools-0.6.6-1-to-python3-setuptools-0.6.6-1-2.diff

The rpmlint output is just one warning:
python3-setuptools-devel.noarch: W: no-documentation
Comment 1 Andrew McNabb 2009-10-29 12:38:03 EDT
1) Probably the sane thing to do would be to call it easy_install-3, right?  That's what has been done with most of the other tools for Python 3, and it looks like python-setuptools-devel installs easy_install-2.6.  It seems to me that it would be fine for the Python 3 version to only install under the versioned name.

2) I assume that when the brp-python-bytecompile patch is in, the __python def will go away, right?

3) The python_sitelib stuff looks a bit hackish, but there might not be any better way to do it.

4) I still think it's insane that easy_install is in the -devel subpackage.  I know that this is a carryover from the python2 packaging, but I think it's worth reconsidering.  If I recall correctly, the rationale was that easy_install depended on some files from python-devel, or something like that.  Anyway, I think it's a disservice to users that the setuptools package doesn't include easy_install.
Comment 2 Dave Malcolm 2009-10-29 13:42:42 EDT
(In reply to comment #1)
Thanks for the feedback.

> 1) Probably the sane thing to do would be to call it easy_install-3, right? 
> That's what has been done with most of the other tools for Python 3, and it
> looks like python-setuptools-devel installs easy_install-2.6.  It seems to me
> that it would be fine for the Python 3 version to only install under the
> versioned name.
It already installs a /usr/bin/easy_install-3.1

It's not clear to me if we need an easy_install-3; we could rename it to that, or drop it.

> 2) I assume that when the brp-python-bytecompile patch is in, the __python def
> will go away, right?

I also used __python in order to override the standard python fragments for getting sitearch/sitelib for setup, build and install.  One of my aims is to minimize the diff against the original specfile.

> 3) The python_sitelib stuff looks a bit hackish, but there might not be any
> better way to do it.
What do you see as hackish about it?   I'm trying to follow the changes proposed here:
https://www.redhat.com/archives/fedora-packaging/2009-October/msg00042.html
to these: https://fedoraproject.org/wiki/Packaging:Python
(which work around the "print" change from 2 to 3; again trying to keep the 2 and 3 versions in sync)


> 4) I still think it's insane that easy_install is in the -devel subpackage.  I
> know that this is a carryover from the python2 packaging, but I think it's
> worth reconsidering.  If I recall correctly, the rationale was that
> easy_install depended on some files from python-devel, or something like that. 
> Anyway, I think it's a disservice to users that the setuptools package doesn't
> include easy_install.  
I want to stick as close as possible to the python 2 version of the package, so I'd suggest taking that up as a separate bug report against that package.
Comment 3 Andrew McNabb 2009-10-29 14:33:34 EDT
(In reply to comment #2)
> > Anyway, I think it's a disservice to users that the setuptools package doesn't
> > include easy_install.  
> I want to stick as close as possible to the python 2 version of the package, so
> I'd suggest taking that up as a separate bug report against that package.  

I actually did once, as bug #510659.  The action to move easy_install from python-setuptools to python-setuptools-devel was made in response to bug #240707.  I'll reopen my bug report and give some more detailed information, but that really doesn't have any bearing on the python3-setuptools package.

The python3-setuptools-devel package has two files:

1) /usr/bin/easy_install-3: a 9 line script that imports and runs pkg_resources.load_entry_point

2) /usr/lib/python3.1/site-packages/easy_install.py: a 5 line script that loads and runs setuptools.command.easy_install.main

The actual dependency on python3-devel happens in the setuptools libraries, not in these trivial scripts, so the python3-setuptools package is the one that should depend on python3-devel package.  This is a simple matter of incorrect dependencies in the specfile, and the packaging guidelines make it pretty clear that python3-setuptools needs to depend on python3-devel (or the files it depends on need to move from python3-devel to python3).
Comment 4 Andrew McNabb 2009-10-29 14:51:07 EDT
(In reply to comment #2)

> It already installs a /usr/bin/easy_install-3.1
> 
> It's not clear to me if we need an easy_install-3; we could rename it to that,
> or drop it.

I think it would be good to have an easy_install-3, so that there's more continuity with upgrades from 3.1 to 3.2 to 3.3, etc., but that's just my opinion.


> I also used __python in order to override the standard python fragments for
> getting sitearch/sitelib for setup, build and install.  One of my aims is to
> minimize the diff against the original specfile.

I would think that the goal would be more to set the standard for Python 3 packaging, especially since there aren't any packaging guidelines yet.  Not that I know what the right thing is. :)


> > 3) The python_sitelib stuff looks a bit hackish, but there might not be any
> > better way to do it.
> What do you see as hackish about it?   I'm trying to follow the changes
> proposed here:

Sorry, I was totally wrong on that.  Thanks for the links.
Comment 5 Andrew McNabb 2009-10-29 15:07:57 EDT
(In reply to comment #3)
> 
> The actual dependency on python3-devel happens in the setuptools libraries, not
> in these trivial scripts, so the python3-setuptools package is the one that
> should depend on python3-devel package.  This is a simple matter of incorrect
> dependencies in the specfile, and the packaging guidelines make it pretty clear
> that python3-setuptools needs to depend on python3-devel (or the files it
> depends on need to move from python3-devel to python3).  

Hmm.  It turns out that the dependency is actually in distutils, which is part of the python3 package.  I'll make a comment on this over on the python3 packaging page and open a separate bug report for python2.  Once these are fixed, setuptools packaging can be made sane. :)
Comment 6 Toshio Ernie Kuratomi 2009-10-29 21:01:39 EDT
For /usr/bin/easy_install -- I think we want to leave the non-versioned /usr/bin/easy_install out of this package and just ship it in the python-setuptools package.  At some point we'll want to have a flag day and switch default over from the python2 packages to python3 packages.

An alternative to that is to use environment-modules to switch between easy_install versions.

====

One advantage of using __python3 rather than overriding __python is that we can put the macros into the python and python3 packages (or python-devel and python3-devel packages.  Whichever makes more sense).  We do this for other languages but we've never asked about doing it for python.
Comment 7 Thomas Spura 2010-01-31 20:43:30 EST
Because this is done in the python-setuptools package

-> closing

*** This bug has been marked as a duplicate of bug 531895 ***

Note You need to log in before you can comment on or make changes to this bug.