Python package file type
Most of pypi is source distributions (zip/tgz), some of it is eggs, some are msi/exe windows installers. When I started with python I found it a bit confusing, which distribution do I need? "setup.py install" isn't obvious. Do you need an installer for each and every OS? Would it be nice if all of python packages behaved a bit more like firefox extensions (just as an example). Let's say all the packages are still zip/tgz files but with the extension "pypack". Whenever python 4 (a future version :) is installed it registers to handle the package filetype with the operating system. So on pypi each package can have one big and pretty "Install" button. After clicking - you get a nice and native installation wizard which asks: 1. Express Install (here it'll automatically install the package to all installed & compatible python versions) 2. Custom (here you can extract the package somewhere or other advanced package stuff) All packages would have the same installer framework that would simply be a GUI for setup.py. What do you guys think, could this be useful? --Yuval
On Wed, Mar 9, 2011 at 4:39 PM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
What do you guys think, could this be useful?
Yes, but there's a lot of heavy lifting to be done before something like that is possible in practice. Currently, a lot of the associated developer energy is focused on the "distribute" package, as well as other projects such as pip and virtualenv. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I agree, it's definitely not a simple task. I'd say to be somehow viable these would be the minimum requirements: * Registration of the file type * Detection of installed python runtimes. * Installer user interface that wraps the main setup.py flows. I might find the time to work on a POC for windows though I'd rather hear some python-ideas feedback before I embark on such a journey. One gripe that comes to mind is the fact that some people might like the .tar.gz file type and never want to switch over. --Yuval
On 3/10/2011 4:43 PM, Yuval Greenfield wrote:
Part of the problem is that there are at least two categories of use cases. Simple: one has one package (in the import sense). This can include a README and other non-python files. Zip it, ship it. Recipient unzips into site-packages. All done. Complex: anything else. -- Terry Jan Reedy
This seems to only focus on systems that *have* GUIs. Aren't they only a fraction of the systems that end up needing to install python packages regularly?
On Wed, Mar 9, 2011 at 4:39 PM, Yuval Greenfield <ubershmekel@gmail.com> wrote:
What do you guys think, could this be useful?
Yes, but there's a lot of heavy lifting to be done before something like that is possible in practice. Currently, a lot of the associated developer energy is focused on the "distribute" package, as well as other projects such as pip and virtualenv. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I agree, it's definitely not a simple task. I'd say to be somehow viable these would be the minimum requirements: * Registration of the file type * Detection of installed python runtimes. * Installer user interface that wraps the main setup.py flows. I might find the time to work on a POC for windows though I'd rather hear some python-ideas feedback before I embark on such a journey. One gripe that comes to mind is the fact that some people might like the .tar.gz file type and never want to switch over. --Yuval
On 3/10/2011 4:43 PM, Yuval Greenfield wrote:
Part of the problem is that there are at least two categories of use cases. Simple: one has one package (in the import sense). This can include a README and other non-python files. Zip it, ship it. Recipient unzips into site-packages. All done. Complex: anything else. -- Terry Jan Reedy
This seems to only focus on systems that *have* GUIs. Aren't they only a fraction of the systems that end up needing to install python packages regularly?
participants (4)
-
Daniel da Silva -
Nick Coghlan -
Terry Reedy -
Yuval Greenfield