Last Update: 29.09.2009. By kerim in python
Today i read a post on why python deployment sucks. Reading through it i had to agree very often. I think nothing that is mentioned in that post is actually new or hasn’t been “thought” about by most. Well at least i have thought about it several times in the past. What was missing however was (as usual) a solution.
I am not really the absolute specialist when it comes to such questions in conjunction with Python. But taking a look around at other languages i think its not really that difficult to come up with some “theoretical” solution that would work, provided one could muster the time and people to actually implement and promote it.
Microsoft has done it and frankly it is a good solution. Why not establish a versioned “standard” framework for Python including not only Python with its included batteries but a bit more than that. Components and libs that work in conjunction with one another so that we have a more stable basis for programs. This framework would also register itself as the handler of python files and perhaps include an update function.
In order to make it easier for the user we should create binary applications that contain a functional exe (in the case of windows) that downloads the framework if it is not installed already. This way we would reduce the need for inexperienced people (or lazy ones) to download it manually or to spend too much time reading the requirements of the software.
All this would allow us to distribute sourcecode or perhaps “compiled” pycs to each other without any problem (except for the base binary with the installer). Our installation routines would only have to set the startup menues and the icons as well as copy the scripts to the apropriate directory.
But actually we could do more than just that…
One of my worst nightmares when it comes to python is the “required libs” section in the installation instructions. I would LOVE to have a function in the standard lib (or the .P-Framework) that would allow to dynamically load needed packages. My idea would be to expand the standard import mechanism. Something like:
would lead the interpreter to look locally for the package “myPackage” with a version of 2.0 or greater. If he doesn’t find it then he should simply shop in the cheeseshop (or who knows where), download and install it and then continue with the program. Using that mechanism you wouldnt have the problem of downloading half a dozen packages from the net before you can try a program of 200KByte length.
Now of course all these ideas are as usual just that… ideas. I would hope for someone to actually pick them up and write a good and decent PEP for it or simply do it. I know it sounds pretty arrogant to ask such features from someone else and not do it yourself. Frankly i think this is not even something that can be done by one person alone, even if he had the time.
Your comments ?
Want content like this in your inbox
each workday irregularly? No BS, spam or tricks... just useful content: