[Python-Dev] Generally boared by installation (Re: Setting project home path the best way)
tismer at stackless.com
Fri Nov 16 00:10:09 CET 2012
I am bored of installing things.
Bored of things that happen to not work for some minor reasons.
Reasons that are not immediately obvious.
Things that don't work because some special case was not handled.
Things that compile for half an hour and then complain that something is not as expected.
May it be a compiler, a library, a command like pip or easy-install, a system like macports or homebrew,
These things are all great if they work.
When they do not work, the user is in some real trouble. And he reads hundreds
Of blogs and sites and emails, which all answer a bit of slightly related questions, but all in all -
This is not how Python should work !!
I am really bored and exhausted and annoyed by those packages which
Pretend to make my life eadier, but they don't really.
Something is really missing. I want something that is easy to use in all
cases, also if it fails.
Son't get me wrong, I like things like pip or virtualenv or homebrew.
I just think they have to be rewritten completely. They have the wrong assumption that things work!
The opposite should be the truth: by default, things go wrong. Correctness is very fragile.
I am thinking of a better concept that is harder to break. I thin to design a setup tool that is much more checking itself and does not trust in any assumption.
After hours and hours, I find how to modify setup.py to function almost correctly for PySide.
This was ridiculously hard to do! Settings for certain directories, included and stuff are not checked when they could be, but after compiling a lot of things!
After a lot of tries and headaches, I find out that virtualenv barfs on a simple
link like ./.Python, the executable, when switching from stock Python to a different (homebrew) version!!
This was obviously never tested well, so it frustrates me quite a lot.
I could fill a huge list full of complaints like that if I had time. But I don't.
Instead, I think installation scripts are generally still wrong by concept today and need to
be written in a different way.
I would like to start a task force and some sprints about improving this
My goal is some unbreakable system of building blocks that are self-contained with no dependencies, that have a defined interface to talk to, and that know themselves completely by introspection.
They should not work because they happen to work around all known defects, but by design and control.
Whoever is interested to work with me on this is hereby honestly welcomed!
Cheers - chris
Sent from my Ei4Steve
On Nov 15, 2012, at 10:17, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
> When python is being run from a compile environment, it detects this by looking for "Lib" folders in directories above the one containing the executable.
> (I always thought that this "special" execution mode, hardwired in, was a bit odd, and suggested that this could be made a function of pep405)
> Anyway, keeping your executable as part of the tree is the trick I use, and to make things nice I put right next to it:
> sitecustomize.py is where you would put the logic to set sys.path by walking up the hierarchy and finding the proper root.
> site.py is there to merely import sitecustomize.py, in case a site.py is not found in all the default places python looks.
>> -----Original Message-----
>> From: Python-Dev [mailto:python-dev-
>> bounces+kristjan=ccpgames.com at python.org] On Behalf Of Christian Tismer
>> Sent: 11. nóvember 2012 20:31
>> To: python-dev at python.org
>> Subject: [Python-Dev] Setting project home path the best way
>> Hi friends,
>> I have a project that has its root somewhere on my machine.
>> This project has many folders and contains quite some modules.
>> There is a common root of the module tree, and I want to use
>> - either absolute imports
>> - relative imports with '.'
>> - I want to run any module inside the heirarchy from the command-line
>> - this should work, regardless what my 'cwd' is
>> - this should work with or without virtualenv.
>> So far, things work fine with virtualenv, because sys.executable is in the
>> project module tree.
>> Without virtualenv, this is not so. But I hate to make settings like
>> PYTHONPATH, because these are not permanent. .
>> How should I define my project root dir in a unique way, without setting an
>> environment variable?
>> What is the lest intrusive way to spell that?
>> I'd like to make things work correctly and unambigously when I call a script
>> inside the module heirarchy. Things are not fixed: there exist many
>> checkouts In the file system, and each should know where to search its
>> home/root in the tree.
>> Is this elegantly possible to deduce from the actually executed script file?
>> Cheers - chris
>> Sent from my Ei4Steve
>> Python-Dev mailing list
>> Python-Dev at python.org
>> Unsubscribe: http://mail.python.org/mailman/options/python-
More information about the Python-Dev