Should we provide that as an abstraction in the wagon maybe so that it allows for easy importing?

On Thu, Nov 24, 2016 at 3:49 PM Nick Coghlan <> wrote:
On 24 November 2016 at 16:45, Nir Cohen <> wrote:
> Well, creating on Windows and deploying on Linux will only be possible if
> the entire set of dependencies either have no C extensions or are manylinux1
> wheels.. but yeah, that's pretty much what we're doing right now with our
> reference implementation.
> Regarding zipimporter, as far as I understand (correct me if I'm wrong)
> there's no such a solution for wheels (i.e. you can't use zipimporter on a
> zip of wheels) so does that means we'll have to package python files for all
> dependencies directly in the archive?

Right, there would be a couple of significant barriers to doing this
in the general case:

- firstly, wheels themselves are officially only a transport format,
with direct imports being a matter of "we're not going to do anything
to deliberately break the cases that work, but you're also on your own
if anything goes wrong for any given use case":
- secondly, I don't think zipimporter handles archives-within-archives
- it handles directories within archives, so it would require that the
individual wheels by unpacked and the whole structure archived as one
big directory tree

Overall, it sounds to me more like the "archive an entire installed
virtual environment" use case than it does the "transfer a collection
of pre-built artifacts from point A to point B" use case (which, to be
fair, is an interesting use case in its own right, its just a slightly
different problem).


Nick Coghlan   |   |   Brisbane, Australia