On Thu, Jan 30, 2014 at 11:59 AM, Donald Stufft <donald@stufft.io> wrote:
>
> On Jan 30, 2014, at 11:33 AM, Evgeny Sazhin <eugene@sazhin.us> wrote:
>
>> On Thu, Jan 30, 2014 at 3:09 AM, Paul Moore <p.f.moore@gmail.com> wrote:
>>> On 30 January 2014 05:33, Evgeny Sazhin <eugene@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?
>
> Because C extensions are not "elite", they are pretty common. It's somewhat
> rare in my experience to see a non trivial project that doesn't have a C
> extension somewhere in it.

Isn't this a self contradictory statement? C extensions are quite
common for non-trivial project. non-trivial is not common.
Doesn't it mean that C extensions are rarely used for common trivial
stuff? You also implying that there were non-trivial projects that
didn't need C extensions. Or are you trying to make an argument that
the overall majority of python projects have C extensions?

Is python
such a bad language it cannot deal with simple stuff without C being
involved?

>
>>
>> 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?
>
> i consider the fact that they'll only work in a subset of situations bad,
> because it's non obvious without digging through the code if any
> particular project will support working from a place other than
> a traditional install.

The necessity to dig through the code to understand if the project is
runnable from zip is a responsibility of project provider - i.e. poor
documentation.
If the project is designed to be run that way the doc should say so.

>This isn't a new feature, Eggs have had this for
> a long time and when confronted with bugs caused by zipped Eggs
> the common solution is simply adding zip_safe=False to their project
> which disables zipped eggs for that project.
>
> The name for the kind of feature this is, is an "attractive nuisance". They
> look like something that might work, especially to people coming to
> Python from other languages such as Java, but if actually use the
> feature in a non trivial fashion you're going to end up with more
> problems then you've solved when random projects simply don't work
> and the likelihood that their authors have no desire to support running
> through a zipped file even if they *could* make it possible.

OK, you're saying " if actually use the feature in a non trivial fashion"
But was is non-trivial in putting pure python wheel in sys.path?
Non-trivial would probably
mean trying to load c extension from it, but that's obviously not supported,
so i wouldn't even try.


Thanks,
Eugene

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig