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 <ncoghlan@gmail.com> wrote:
On 24 November 2016 at 16:45, Nir Cohen <nir36g@gmail.com> 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":
https://www.python.org/dev/peps/pep-0427/#is-it-possible-to-import-python-co... - 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).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia