On Thu, Jan 30, 2014 at 12:23 PM, Evgeny Sazhin <eug...@sazhin.us> wrote: > On Thu, Jan 30, 2014 at 11:48 AM, Donald Stufft <don...@stufft.io> wrote: >> >> On Jan 30, 2014, at 11:44 AM, Evgeny Sazhin <eug...@sazhin.us> wrote: >> >>> On Thu, Jan 30, 2014 at 9:38 AM, Donald Stufft <don...@stufft.io> wrote: >>>> >>>> On Jan 29, 2014, at 11:29 PM, Evgeny Sazhin <eug...@sazhin.us> wrote: >>>> >>>>> >>>>> On Jan 29, 2014, at 11:17 PM, Donald Stufft <don...@stufft.io> wrote: >>>>> >>>>>> >>>>>> On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin <eug...@sazhin.us> wrote: >>>>>> >>>>>>> >>>>>>> On Jan 29, 2014, at 10:49 PM, Donald Stufft <don...@stufft.io> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin <eug...@sazhin.us> wrote: >>>>>>>> >>>>>>>>>> >>>>>>>>>> Wheel is a package format. Packages are for transmitting and >>>>>>>>>> installing bits. If you want to make some kind of self-unpacking >>>>>>>>>> executable please do it with something built for it. makeself is an >>>>>>>>>> excellent choice for these. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I didn't say anything about self-unpacking executable. Egg already >>>>>>>>> knows to do what is needed, so i was correct in expecting the wheel >>>>>>>>> to do the same. Plus the notion of packages for transmitting and >>>>>>>>> installing should not exclude the running and importing. Otherwise it >>>>>>>>> is useless, at least for my purposes. As discussed before - jar does >>>>>>>>> that just fine and it is a package format. >>>>>>>>> >>>>>>>>> Funny thing - wheel allows to do the same! Why would i want to use >>>>>>>>> anything else then??? >>>>>>>> >>>>>>>> Because Python is not Java and Wheels are not Jars. You'll find very >>>>>>>> few packages actually support being run from a zipped file and the >>>>>>>> failure modes are not always obvious. >>>>>>> >>>>>>> I understand that not a lot of currently existing project are using >>>>>>> this capability - but I'm 100% positive that if the running from wheel >>>>>>> would be properly supported on error handling level and officially >>>>>>> declared at least for the pure python - most of the people would be >>>>>>> happy to have that! If we think about that, why would i want to use >>>>>>> anything else other than wheel and pip if this pair gives the >>>>>>> possibility to >>>>>> >>>>>> Pip does not install zipped wheels, and while it's not entirely up to me >>>>>> I would be opposed to it getting the ability to do so. >>>>> >>>>> I might be poorly wording things - but i never said I want pip to install >>>>> the zipped wheel. It seems that you're missing the point a bit. >>>>> I'm totally fine with the way pip handles things. >>>>> >>>>> again briefly My idea is to use the following: >>>>> >>>>> central location - flat folder with wheels, accessible to read for >>>>> everybody in network. >>>>> >>>>> for development : pip and virtual env. project has the virtual env >>>>> created, dependencies are deployed and available for development and >>>>> debugging in a standard manner. When done the project is packaged into >>>>> wheel that is getting deployed to central location. >>>>> >>>>> To *run* the program: i would create a script that bases on the pip >>>>> ability to resolve dependencies and basing on the requirements.txt from >>>>> inside my wheel it would generate PYTHONPATH to prepend the starting call >>>>> like that: >>>>> PYTHONPATH=1.whl:2.whl; python 3.whl >>>>> >>>>> where 3.whl is program with __main__.py and 1.whl and 2.whl are >>>>> dependencies needed. This works as of now! >>>> >>>> Just use pip and virtualenv in production. It's bad form to install things >>>> differently in development than in production. It *will* lead to >>>> production only bugs and in the case of zip imports it'll lead to hard to >>>> diagnose errors and bugs that you'll never be able to reproduce in >>>> development. >>> >>> >>> I'm happy to concede the run from zip thing if somebody could explain >>> how should i use pip and virtualenv in production? >>> Currently it seems to be very clean and clear. I can have one folder >>> where i can dump multiple versions of the same project in wheel format >>> and having requirements.txt in each of them i can construct PYTHONPATH >>> and run things. Simple! >>> >>> How am i supposed to manage that using pip and virtual envs in production? >> >> The same way you'd use them in development? Hell I believe you can even do: >> >> $ virtualenv my_virtualenv >> $ my_virtualenv/bin/pip install path/to/wheelhouse/* >> >> The point is it's just installed libraries, asking this question doesn't >> really make much >> sense, it's like asking how do you use apt-get or yum in production. >> >>> > > Could you please reread this > https://mail.python.org/pipermail/distutils-sig/2014-January/023636.html > I'm explaining there what is the task at hand and why I'm favoring the > jar-like workflow for deployment.
It's clear that you favor the jar-like workflow. You will have discover for yourself why it works or does not work for you. There is more mature existing jar-like support for eggs (which will continue to work for some time, but not be improved). We do actually need a better way to turn libraries on and off individually, for example, if I install the wrong set of Python libraries on Ubuntu the plugin system for somesuch package crashes; having everything installed importable all the time is a problem. Even if you don't consider the unrelated packages that have chosen the same module name. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
