One thing that might be useful would be to develop the "unpacked wheel" which is currently undefined but would be deliberately identical to a site-packages with just one wheel extracted into it. You wouldn't have to argue or worry about the zip issue. I like the way npm puts everything into a directory ~/.npm/packagename/0.4.2/ ... for example, gem is similar. If you really wanted to go to town you could figure out how to do virtualenvs with hardlinks or reflinks instead of copies (conda can). But as has been repeated you won't find robust support for this in the existing code. On Thu, Jan 30, 2014 at 1:19 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
On Thu, Jan 30, 2014 at 12:56 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 30 January 2014 16:33, Evgeny Sazhin <eugene@sazhin.us> wrote:
I don't have good references or pointers to good Python development or deployment practices, but you may want to ask around on python-list.
And that is my biggest concern (deployment). I believe these questions should be answered by wheels or python packaging specification. Not by third party tooling. The language should be able to work with artifacts/packages produced for the language by the language. Third party tools may allow for automation, continuous integration complicated deployments and whatnot. But the base must be there.
There's 2 distinct concepts in the Python world, that you should be aware of. Application deployment and library deployment.
Library deployment is simple. Build your library and upload it as a source distribution (sdist) and one or more wheels to PyPI (if it's a public project) or a local index (if it's a private project). People or other projects will use the library however they deem appropriate, typically by doing "pip install projectname" to make the code accessible. That unpacks the wheel into a local site-packages, but you have no need to care about that.
Application deployment is not as straightforward - there are a number of common approaches and at least as many opinions on what you should do. You may bundle Python and your code and its dependencies together into a standalone executable, using a tool like cx_Freeze. or you may use something like buildout (I can't give details as I've never used this). You can also, in some cases, package your application main code in the same way as a library, and use "entry points" to define the executables - that will then be installed by the end user into an existing Python installation.
As an application developer, you typically wouldn't care about how the end user deployed your code for execution, unless you were bundling via something like cx_Freeze. You might choose to bundle your application code *without* a Python interpreter. That's basically what executable zipfiles are about, and it's probably the closest equivalent to Java jars. But that's not a particularly well-travelled route in the Python community (yet) - there are projects like pyzzer that automate certain aspects of that process, but in general, you have to "roll your own" solution here.
Hopefully that makes some sense - I'm getting pretty burned out with the various threads going on at the moment, so I'm probably glossing over a lot.
Cheers, Paul
Thanks Paul - you are very helpful! this is good distinction and i think i'm coming to it as well. I just suggested one approach that might be feasible in my case in another thread;)
Everybody - I'm really grateful for the time you are willing to spend in helping me to understand the state of the things. I hope this discussion might be helpful for both sides and may be people like me can be referenced to it in future;)
PS That doesn't mean i will stop arguing with you;)
Thanks, Eugene _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig