Bug 531648

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.

(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.

(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).

(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.

(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. :)

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.

Because this is done in the python-setuptools package

-> closing

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