On Jan 29, 2014, at 9:50 AM, Evgeny Sazhin <eug...@sazhin.us> wrote:
> > > > On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > Does it mean that it actually makes sense to look into that > > direction and make wheel usage closer to jar? > > There is a parallel discussion going on, with the title "Using Wheel with > zipimport", > which is relevant to this question, and other questions you raised (e.g. about > supporting C extensions/pure-Python modules. > > > I read all of it and got a bit lost in between the distil API and PEP process > discussion;) > > > > I have no knowledge about c extensions scope, but i feel > > like it might be of less importance then pure python > > packaging issues? Am I wrong? > > A lot of Python users depend on C extensions - and while it is a subset of > all Python > users, it is a large (and important) subset. Example: any usage of Python in > numerical analysis or scientific applications involves use of C extensions. > > Regards, > > Vinay Sajip > > > I can see that it might be quite beneficial to have virtualenv and pip > installing wheels locally for development needs, so here is what i was able > to come up with so far: > > I have one folder on NFS where all python developed stuff should be > *deployed* - pyhtonlib. It is impossible to use pip or virtualenv there - so > i'm bound to artifacts. The only way something can appear there is by using > the "release" program that knows how to put artifacts in specified locations. > Currently most of the stuff there is the .py modules and few eggs (some are > executable). But this stuff is not allowing for sane dependency management, > neither code reuse. I actually don't like the idea of specifying dependencies > in the code via sys.path. I think the resolved sys.path based on > requirements.txt is much better solution. > > So i'm looking for a solution that would allow to use the same artifact for > everything (like jar) so it can guarantee that the same subset of code that > was tested, goes to production and used in dev. Currently I'm leaning towards > using pip's capability to work with flat folders via --find-links, so i can > deploy wheels to the pythonlib and then reuse them in the development > environment. > > But in this setup how do i make my program executable from pythonlib > location? I think I should I create some smart runner script that would be > able to use the pip's dependency resolution, create the necessary sys.path > basing on the wheel requirements.txt and then my program wheel should have an > entry point like __main__.py > > As Nick pointed out the wheel is a superset of the egg - so I assume wheels > can be executable, correct? How do i achieve that? 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. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
