Make Wheel.is_mountable False by default

Issue #95 new
created an issue

As of now, the method is_mountable is hard-coded to return True:

This doesn't pose problems in normal situation, since pip install doesn't normally mount wheels on installation anyway, but it leads to a problem when 3rdparty libraries trust this flag, e.g. like humpty does. That lib takes is_mountable=True as the fact that the resulting egg would come out zip-safe, which is not true for packages containing arbitrary data, like jinja templates.

I'd say is_mountable=False is a safer stub to have, as it should not create false expectations.

Comments (4)

  1. Vinay Sajip

    But the flag only applies to wheel files, and says nothing about the zip-safety of any egg. Isn't this a problem for humpty to fix? If a wheel has properly written code (i.e. code that knows it might be run from a zip, and doesn't blindly look for resources in the filesystem) there is no reason it needn't work properly, even if mounted as a zipfile.

  2. i reporter

    I have a package that's suboptimal in what you call "blindly look for resources in the filesystem": it uses uses jinja templates that it ships with itself as package data, but it states it clearly with zip_safe=False in I can't seem to find any trace of that flag in the resulting wheel, but it seems to work with wheels, because they are extracted during installation anyway.

    Now, as far as I understand the code, there's a stub right now in distlib that says that all wheel files are safe to be "mounted", i.e. run without being installed. It is not strictly true and would cause problems if someone tried to mount wheels that are actually unmountable (like in my case). I'm not very experienced with packaging, but if I had to guess, I'd say very few people would want to mount a wheel as long as pip is able to install it without headaches, so it's likely that no one has run into this problem just yet.

    My point here is that despite "mountable=False" is also incorrect, i.e. the majority of wheels are still safe to be run without extracting them, it's a safer value because it's not providing false expectations. And it would be more correct to show a warning to the user who tries to "mount" a wheel that "there's no metadata to know whether or not the wheel is safe to be mounted", rather than to run silently and fail.

    Humpty's take in this situation is as follows: if a wheel is "mountable", then the egg that would be created from it is "zip-safe". And easy_install doesn't extract eggs that are zip-safe, it's easier to encounter the problem. I have proposed a PR) to work around the stubbed value in distlib in the meantime, but it feels like a wrong place to do so.

  3. Vinay Sajip

    I'd say very few people would want to mount a wheel as long as pip is able to install it without headaches

    Well, numerous people on distutils-sig have said they are against mounting wheels, period, but I had already added the mount() functionality because I thought it would be useful in various scenarios. I had planned to introduce some metadata which could be used to determine mountability, but that might require changes to the wheel project (to write the relevant metadata) and since the movers and shakers on distutils-sig don't seem too keen on mounting wheels, I'm not sure I can count on any cooperation in this area to come up with a common approach.

    I don't want to change the default value of is_mountable() as it could well break existing code that relies on that default. The problem can perhaps be solved, or at least mitigated, by telling users more prominently that mounting wheels is at their own risk. I will have a think about alternative approaches.

    I haven't looked at the humpty project before but I will look more closely when I get a chance. I note in passing that it prominently says

    Currently, the tool is in a 'works for me' state. (It is not guaranteed to work for you.)

    So I'm not sure one can really rely on the tool doing what one wants as time progresses.

  4. i reporter

    Currently, the tool is in a 'works for me' state. (It is not guaranteed to work for you.)

    looks like a human way of providing a standard disclaimer, like the one in GPL or MIT licenses:


  5. Log in to comment