Date: Thu, 6 Feb 2014 21:08:03 +0100 From: Marcus von Appen <mva@FreeBSD.org> To: freebsd-python@freebsd.org Cc: portmgr@FreeBSD.org Subject: Re: Multiple logical packages from a single source port Message-ID: <20140206200803.GB1417@medusa.sysfault.org>
next in thread | raw e-mail | index | archive | help
--H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Full quoting my initial message below for portmgr@. The exp-run for the logical packages has finally been done and the results are available at ports/185947. From what I could see by quickly glancing over the ports, the impact is rather small and only a couple of ports need to be fixed prior to commit. If all things go well, we should be able to commit the change the next week. portmgr@: Since the package layout (directories, files) of certain ports (those using USE_PYDISTUTILS) will be changed, I wonder, if we should also bump the PORTREVISIONs for all of those. Cheers Marcus On, Thu Dec 19, 2013, Marcus von Appen wrote: > Dear all, > > now that we removed lang/python from bsd.python.mk, we need to enable > python ports to be built and installed for different python versions > without creating conflicts. > Looking at the TODO list, which I posted ages ago, this should be the > very last thing before the ports tree is able to support different > Python versions at the same time (the pkg tools are not, but that > another issue to deal with). > > Many python ports install binaries (or scripts), docs, additional data > and other things besides their modules. While the latter, the modules, > already support different python versions out of the box (since they are > usually installed locally into a version-specific site-packages folder), > the first do not. > > DATADIR, DOCDIR, WWWDIR and ETCDIR follow a <PREFIX>...<PORTNAME> > layout, and as such use the same directory for different python > versions. Binaries are often installed as defined by the upstream port > and as thus are not distinct when it comes to different python versions. > > To work around this limitation and to enable ports as well as packages > to be installed for different python versions at the same time, the > current standard behaviour has to be tweaked. > > I'd propose that standard directories, which currently use the PORTNAME > as identifier, shall carry a python version prefix. Binaries shall carry > a python version suffix, but shall be symlinked to their original name, > if the python version of the port matches the default python version > choice of the user. > > What does that mean in practice? Assume, we have port devel/py-foo, > which, at this very moment, uses the following installation layout for > Python 2.7 (being the chosen default of the user): > > bin/foo > lib/python2.7/site-packages/foo/__init__.py > lib/python2.7/site-packages/foo/bar.py > lib/python2.7/site-packages/foo/foofoo.py > share/foo/bar/some.dat > share/foo/arbitrary.dat > share/doc/foo/README > > In a prefixed ports world, the installation layout would be: > > bin/foo-py27 > bin/foo [links to]-> bin/foo-py27 > lib/python2.7/site-packages/foo/__init__.py > lib/python2.7/site-packages/foo/bar.py > lib/python2.7/site-packages/foo/foofoo.py > share/py27-foo/bar/some.dat > share/py27-foo/arbitrary.dat > share/doc/py27-foo/README > > If the user chooses to install devel/py-foo for a non-default python version > 3.3, the installation layout would be: > > bin/foo-py33 > lib/python3.3/site-packages/foo/__init__.py > lib/python3.3/site-packages/foo/bar.py > lib/python3.3/site-packages/foo/foofoo.py > share/py33-foo/bar/some.dat > share/py33-foo/arbitrary.dat > share/doc/py33-foo/README > > If the user would make Python 3.3 the default version and rebuild and > reinstall the port for 2.7 and 3.3, a symlink bin/foo --> bin/foo-py33 > would appear instead of bin/foo --> foo-py27. > > Certainly docs, data and other shared content would duplicate, but this > is safer, easier to maintain and less error-prone than to use shared > directories and lots of conditional magic in the installation and > deinstallation logic. > > I created a POC as USES, named uniquefiles.mk, which can be used by > nearly every port (even non-python ones). For USE_PYDISTUTILS, > it would be implicitly used, other ports, e.g. autotools-based ones > installing python modules, would need to pull in the python specific > paramters via UNIQUE_PYTHON_FILES=yes. > > Q: Do I have to touch the plists to enable support for it? > > No. The port logic will do that for you. You must not add a > prefixed or suffixed binary name, though, but the original name > only. In short, you MUST NOT add things like > > bin/foo-py27 or > bin/foo-py32 or > sbin/foo-py33 > ... > > if the upstream package does not create those files (which is > unlikely). > > Q: So nothing to be done for me? > > Right. Just watch your plists on updating. > > Q: UNIQUE_PYTHON_FILES? > > Yes. If you are maintaining a python port, which does not use distutils (no > USE_PYDISTUTILS=... in the Makefile), UNIQUE_PYTHON_FILES is what you want. > Ports using USE_PYDISTUTILS will implicitly configure everything, so that > DOCDIR, DATADIR, ... and binaries will be properly prefixed and suffixed. > Your python port however does not use USE_PYDISTUTILS, so you can help > yourself using UNIQUE_PYTHON_FILES=yes. > > Q: Can I use it for my own port? It does not use python, though... > > Of course. uniquefiles.mk is a USES, thus each and every port can utilise > it. Please refer to its inline comments for further details about how to > configure and use it. > > A patch for the current ports tree can be found at > http://people.freebsd.org/~mva/python_unique_ports.diff > > If you just want to try out the uniquefiles feature, you can find a > separate diff at > http://people.freebsd.org/~mva/uniquefiles.diff > > Readers are encouraged to give those patches a try in an own jail > :-). So far, I only tested them briefly, but will do more tests the next > days. > > Cheers > Marcus --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlLz66MACgkQi68/ErJnpkdpUACgoSqmT+Y5E3r6IRSpKruxs5jp twMAoKffSrCAP8YlGmsI5JebNHUa8lGa =9ycv -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140206200803.GB1417>