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! > >> 1. use minimum of “standard” tools, >> >> 2. *manage dependencies* in a unified and standardized way >> >> 3. use only *one format* and *one artifact* per project for everything >> related to the code development, shipment, deployment and execution. >> >> What would be a motivation to learn yet another tool like buildout or >> anything, pollute infrastructure with more libraries, manage several >> different ways of working with the code, overcomplicate the production area >> by requiring stuff to be unzipped and whatnot? >> >> I hope nobody would want to strip any of those nice features from the wheel, >> but improve the running from it!;) > > I don’t understand what any of the rest of this have to do with wether you > add zipped Wheels to your sys.path or not. see above > >> >> Thanks, >> Eugene >> >>> >>>> >>>> Thanks, >>>> Eugene >>>> _______________________________________________ >>>> Distutils-SIG maillist - Distutils-SIG@python.org >>>> https://mail.python.org/mailman/listinfo/distutils-sig >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
