<div dir="ltr">Should we provide that as an abstraction in the wagon maybe so that it allows for easy importing?</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 24, 2016 at 3:49 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 24 November 2016 at 16:45, Nir Cohen <<a href="mailto:nir36g@gmail.com" class="gmail_msg" target="_blank">nir36g@gmail.com</a>> wrote:<br class="gmail_msg">
> Well, creating on Windows and deploying on Linux will only be possible if<br class="gmail_msg">
> the entire set of dependencies either have no C extensions or are manylinux1<br class="gmail_msg">
> wheels.. but yeah, that's pretty much what we're doing right now with our<br class="gmail_msg">
> reference implementation.<br class="gmail_msg">
><br class="gmail_msg">
> Regarding zipimporter, as far as I understand (correct me if I'm wrong)<br class="gmail_msg">
> there's no such a solution for wheels (i.e. you can't use zipimporter on a<br class="gmail_msg">
> zip of wheels) so does that means we'll have to package python files for all<br class="gmail_msg">
> dependencies directly in the archive?<br class="gmail_msg">
<br class="gmail_msg">
Right, there would be a couple of significant barriers to doing this<br class="gmail_msg">
in the general case:<br class="gmail_msg">
<br class="gmail_msg">
- firstly, wheels themselves are officially only a transport format,<br class="gmail_msg">
with direct imports being a matter of "we're not going to do anything<br class="gmail_msg">
to deliberately break the cases that work, but you're also on your own<br class="gmail_msg">
if anything goes wrong for any given use case":<br class="gmail_msg">
<a href="https://www.python.org/dev/peps/pep-0427/#is-it-possible-to-import-python-code-directly-from-a-wheel-file" rel="noreferrer" class="gmail_msg" target="_blank">https://www.python.org/dev/peps/pep-0427/#is-it-possible-to-import-python-code-directly-from-a-wheel-file</a><br class="gmail_msg">
- secondly, I don't think zipimporter handles archives-within-archives<br class="gmail_msg">
- it handles directories within archives, so it would require that the<br class="gmail_msg">
individual wheels by unpacked and the whole structure archived as one<br class="gmail_msg">
big directory tree<br class="gmail_msg">
<br class="gmail_msg">
Overall, it sounds to me more like the "archive an entire installed<br class="gmail_msg">
virtual environment" use case than it does the "transfer a collection<br class="gmail_msg">
of pre-built artifacts from point A to point B" use case (which, to be<br class="gmail_msg">
fair, is an interesting use case in its own right, its just a slightly<br class="gmail_msg">
different problem).<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Nick.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br class="gmail_msg">
</blockquote></div>