HEADS-UP and RFC - Adding setuptools as default RUN_DEPENDS

[Marcus von Appen]

On, Thu Feb 13, 2014, Volodymyr Kostyrko wrote:

> 13.02.2014 10:11, Kubilay Kocak написав(ла):
> > Two days ago I updated virtualenv, transitioning it away from the
> > deprecated USE_PYDISTUTILS=easy_install to USE_PYDISTUTILS=yes as many
> > other ports have recently.
> >
> > I thought nothing of it until the following report by Scott (cc'd):
> >
> > http://lists.freebsd.org/pipermail/freebsd-python/2014-February/006592.html
> >
> > The summary of that thread is:
> >
> > a) Any python software that uses *console_scripts* needs the
> > pkg_resources module from setuptools at run time. This basically means
> > anything that installs a CLI utility.
> >
> > b) Package-only users don't get setuptools installed when they install
> > the packages of the above ports, because =yes *doesnt* set a RUN_DEPENDS
> > on it.
> >
> > This breaks console script invocation, with the following error:
> >
> > Traceback (most recent call last):
> >    File "/usr/local/bin/<script-name>", line 5, in <module>
> >      from pkg_resources import load_entry_point
> > ImportError: No module named pkg_resources
> >
> > Reproduction steps are:
> >
> > 1) Install port or package that uses console_scripts
> > 2) If you installed the package, run the console script
> > 3) If you installed the port
> > 3.1) Run the console script
> > 3.2) Remove py-setuptools
> > 3.3) Run the console script again
> >
> > Reproduced with: py-virtualenv (`virtualenv`), py-tox (`tox`) and
> > py-nose (`nosetests`)
> >
> > We (python@) have now standardised on a consistent installation pattern
> > for all python software, whether pure-distutils or setuptools based, and
> > there are run-time requirements that are currently not being satisfied.
> >
> > Attached is a patch moving RUN_DEPENDS+=setuptools from the
> > =easy_install only case, to the default case.
> >
> > Patch review requested, other comments welcome.

Looks good to me.

> > ../koobs
>
> This effectively means that user should choose between python2 and
> python3 and all ports that are not from choosen side will stop to
> compile/work?

This already is the case for the majority of ports. pkg is slightly more
robust with packages not introducing a run dependency, but from the ports
framework side is something that works as side effect, not as something
provided by design.

> Like i need to have www/trac, and some other script needs
> databases/py-postgresql. Both require py-setuptools yet trac needs
> py27-setuptools and postgresql driver - py33-setuptools. So there would
> be no easy way to install both?

Unfortunately yes. The problem is within the package management tools at the
moment, since those do not support the installation of two different logical
packages (py27-setuptools and py33-setuptools in thise case) from the same
original source port. This did not work before (as stated above), so
design-wise, we are not stepping backwards.

From the python@ perspective, we are currently working on a clean package
approach to enable support for cases like yours, but no matter how fast we
are, we will have to wait for the official package management tools to catch
up.

Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-python/attachments/20140216/0a7b906b/attachment.sig>