[Python-Dev] issue 9807 - a glitch in coexisting builds of different types (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Sat Oct 2 09:44:16 CEST 2010
- Previous message: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
- Next message: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
With my branch, you'll end up with this in /tmp/python:
bin/python3.2m - the normal build binary bin/python3.2dmu - the wide+pydebug build binary bin/python3.2m-config bin/python3.2dmu-config Do users really want to see such idiosyncratic suffixes? Ordinary users won't be building Python from source. Developers won't care so long as we clearly document the sundry suffixes and describe them in the README (or in a PEP, with a pointer from the README).
I think this is not true. Developers will care, and they will cry foul very loudly, asking what nonsense this is. Antoine is proof of that: he is a developer, and he understands the motivation well, but it still goes against his notions of beauty (channeling him here).
Having multiple parallel "altinstall" installations be genuinely non-interfering out of the box certainly seems like a desirable feature to me.
I think this should not use automatically generated suffixes, though. Perhaps I want an altinstall that is in some kind restrict? Or one where user "peter" has write access into site-packages?
I could accept that a suffix is parameter to configure (or some such), and then gets used throughout. By default, Python will not add a suffix. However, I still wonder why people couldn't just install Python in a different prefix if they want separate installations.
Regards, Martin
- Previous message: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
- Next message: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]