[Distutils] wheels on sys.path clarification (reboot)

[Evgeny Sazhin]

On Thu, Jan 30, 2014 at 3:09 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 30 January 2014 05:33, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>>Eh, I think both 1 and 3 are things that are possibly reasonable to happen and
>>>they are both things that I've contemplated as things to bring forward in
>>>using xz as an alternative compression format. Even if #1 would need a major
>>>revision of Wheel to happen adding official "support" for zip import means that
>>>the change would have to be weighed against also breaking that backwards
>>>compatibility.
>>
>>
>> Eh, please don't break it!! Improve! Keep the ability to add wheels to python path.
>> I don't care how, zip import, non-zip import, whatever - allow for jar-like behavior - people will thank you if it will work properly !;)
>> I know, i'm probably alone in the desert...l;)
>
> This is the biggest concern I see with "promoting" wheels being
> directly importable via zipimport (I say "promoting" and not
> "specifying" deliberately, but I don't want to get back into the
> process debate).
>
> People like Evgeny (no offense intended here, but your post is a good
> example to use) coming from a Java background will see importable
> wheels and *think* that they are similar in purpose to jars.

No offense taken - i'm happy to be a use case to add some perspective;))

>This is
> not, and never will be, true. Python is not Java, deployment by
> putting jar-like files on sys.path is not an advisable workflow for
> Python - no matter what parallels with Java might make it look
> attractive.

For pure python wheels - you're right - very attractive! And while i
hear you guys saying it is not advisable to use wheels in sys.path i'm
still far from seeing good reasoning. Please, correct me, but so far i
saw 2:

1. It is impossible to load C extensions
2. Error handling is bad

None of these reasons seems to be good enough to lead to a conclusion
that wheel used as jar-like thing is not needed. Here is how i see it
(again probably to my lack of knowledge):

1. Yes there is a group of "elite" interesting projects that are using
C extensions together with python code. What i don't understand is why
are wheels supposed to be tailored to the needs of the hybrid projects
instead of making pure python first priority? There is big crowd using
C extensions, but how much bigger is the crowd who doesn't? Why law
abiding pure python developer should jump through the hoops?

2. IF we are talking about error handling it seems that people
generally do not consider jar-like behavior to be bad for pure python
modules - It's just doesn't work very well (yet?). Is there really a
problem with error handling for pure python? What if the error
handling is improved? Is it still going to be bad? Why?

>
> Pointing out the implication that wheels can be put on sys.path in
> specialised circumstances is entirely reasonable when talking to a
> Python audience, but it triggers entirely the wrong associations when
> a person with a Java background sees the statement.
>
> Evgeny - for your purposes, you'd be better advised to see wheels as
> similar in principle to Windows MSI installers (they aren't, but it
> will avoid triggering incorrect analogies).

That is an awesome analogy, thank you!

> 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.

Thanks,
Eugene

> (Be careful,
> you may hear suggestions that you use eggs because they are similar to
> jars - while that is true, the way Python works means that the
> experience with eggs is far from being as natural as the jar
> experience you're used to).
>
> Paul