Restructuring Python ports?
Bryan Blackburn
blb at macports.org
Fri Jan 2 13:16:41 PST 2009
On Fri, Jan 02, 2009 at 11:48:09AM -0500, Randall Wood said:
> I would like to suggest the following:
>
> That for each version of python (pythonxy), there be the following ports:
>
> pythonxy, which installs nothing (maybe a readme file so that macports
> can consider it installed), but which depends on the following:
>
> pythonxy-core, which is analogous to the current python24 and python25
> ports,
>
> pyxy-whatever, which, when all pyxy-whatever ports are installed, provide
> a complete basic python installation of the core modules. (I'm not
> suggesting that every pyxy-* port be installed, only those which are
> required to provide the disabled modules)
>
> We may also want to provide a pythonxy-x11 or pythonxy-core-gui port
> which would include the basic python tk/x11 gui capabilities so that
> pythonxy-core does not include an X11 dependency.
>
> This may provide an advantage over throwing everything into a single port
> in that it would allow the pyxy-whatever ports to be updated
> independently of the pythonxy-core port if they need to be.
Note that those modules which are split out from the python core are only
updated with python itself, so they'd only be updated when the base python
port is also updated.
Also, the way this works currently, it causes these split-out modules to be
installed in site-packages, not lib-dynload (which is where they are
installed when handled with the core python). This then breaks running
python with the -S option:
-S Disable the import of the module site and the site-dependent
manipulations of sys.path that it entails.
since site-packages is part of what is disabled, and lib-dynload is not.
Since there is a >0 number of people using this option [1],[2], unless we
have a good way of installing those modules (and only those, not all python
modules) into lib-dynload, python functions best with all modules built as
it expects.
Bryan
[1] - <http://trac.macports.org/ticket/12369#comment:18>
[2] - <http://trac.macports.org/ticket/14844>
[...]
More information about the macports-dev
mailing list