On Wed, Jan 27, 2016 at 3:47 AM, Nick Coghlan <[email protected]> wrote:
> On 27 January 2016 at 08:36, Nathaniel Smith <[email protected]> wrote: > > On Mon, Jan 25, 2016 at 8:37 PM, Robert T. McGibbon <[email protected]> > wrote: > >> I agree that this is an important detail. I generally use machines that > have > >> many different Python interpreters installed (some distro-provided and > >> others in my home directory), and can easily imagine wanting them to > have > >> different behavior w.r.t. manylinux1 wheels. > >> > >> Perhaps the option could be put in site.py, or somewhere in > >> lib/pythonX.Y/configX.Y/? I'm not sure what the appropriate solution > here > >> is. > > > > On further thought, the site.py solution has sorta grown on me... > > basically the PEP text would look something like: > > > > "If there exists an attribute sys._manylinux1_compatible, then > > bool(sys._manylinux1_compatible) determines whether the given > > interpreter should be considered manylinux1-compatible. By default, > > upstream Python builds will not provide any variable with this name, > > but a distributor may create it if they choose (e.g. from > > sitecustomize.py)." > > > > It's not exactly pretty, but it's kinda elegant: it neatly solves the > > problem of binding the configuration to an individual python > > environment, allows it to be set from site.py or sitecustomize.py or > > from a user's PYTHONSTARTUP or usercustomize.py or even by a local > > patch to the interpreter, it's naturally inherited across > > virtualenv/venvs, can be checked in very little code, and can be > > specified in very few words. > > > > I guess we can bikeshed about whether 'sys' is the appropriate place :-) > > I'd prefer to leave standard library modules out of this if we can - > they're a rabbit warren of political complexity, even when upstream > and redistributors agree on what needs to be done (since > redistributors have customers, and having people pay you tends to make > them even *less* forgiving if you change something in a way that > breaks their systems). > > However, I do like the idea of defining a *Python* API for accessing > the configuration data as the initial solution. Since nothing in the > standard library needs it, it can just be an ordinary module called > "manylinux". > > If "import manylinux" fails, then we're in the "compatibility not > specified" case (or we're not on a Linux system). > > If "import manylinux" works, then the module can give details (perhaps > pulled from a config file, perhaps figured out on the fly by querying > the running system, perhaps hardcoded by the OS vendor) on the > compatibility level. > Fair enough -- how about we use "_manylinux" to emphasize that this is an internal module (as opposed to e.g. some package you'd get on pypi that provides manylinux-related functionality)? It doesn't have as many features as Xavier's suggestion of exporting a generic preference-ordered list combining manylinux tags, distro-specific tags, etc., but that seems a bit premature right now and could always be added on top later (_wheel_tags.py can import _manylinux). -n -- Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
