Merge lp:~mvo/snapcraft/python3-project into lp:~snappy-dev/snapcraft/core
| Status: | Merged |
|---|---|
| Approved by: | Michael Terry on 2015-07-17 |
| Approved revision: | 88 |
| Merged at revision: | 90 |
| Proposed branch: | lp:~mvo/snapcraft/python3-project |
| Merge into: | lp:~snappy-dev/snapcraft/core |
| Diff against target: |
146 lines (+109/-0) 7 files modified
examples/py3-project/meta/package.yaml (+5/-0) examples/py3-project/meta/readme.md (+1/-0) examples/py3-project/sha3sum.py (+15/-0) examples/py3-project/snapcraft.yaml (+6/-0) plugins/python3-project.yaml (+8/-0) snapcraft/plugins/python3.py (+43/-0) snapcraft/plugins/python3_project.py (+31/-0) |
| To merge this branch: | bzr merge lp:~mvo/snapcraft/python3-project |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Terry (community) | 2015-07-13 | Approve on 2015-07-17 | |
|
Review via email:
|
|||
Commit Message
Add python3 plugin
Description of the Change
This is a bit of a RFC branch.
It adds a python3-project plugin for python3 parts. It is not using pip/pypi (for projects not on pypi). My idea was to have a python3-project and a pip3-project. But I do wonder if they should be separate or if python3-project should simply support both and we infer that its pip from the source: option (i.e. "source: pip:pkgname").
The other question I have is what the best layout for my py3-sponeshaker example is. The idea is that its a example that uses a github py3 module to do sha3 and builds a simple cmdline tool on top of this that uses the sha3 python-module. The sha3sum.py is just a single file that needs to be in the top-level of the snap. I wonder if we should have "copy" plugin or something like this that just puts the one file into the snap. What do you think is the best approach here?
And finally - python3 seems to be not have a official linux binary download. Which is a bit of a bummer. But it seems its not too terrible as building on my box takes only ~2min (and ~170mb diskspace). I will look into this next.
| Michael Terry (mterry) wrote : | # |
| Michael Vogt (mvo) wrote : | # |
Thanks! I renamed the example and addressed the inline comments. Having a python3-project and a pypi3/pip3 plugin sounds reasonable. I create a branch on top of this one for the copy plugin so that the example is complete (lp:~mvo/snapcraft/copy-plugin). The example snapcraft.yaml is slightly different from the above proposal as there is no "project" yet AIUI. Should be trivial to migrate though.
| Barry Warsaw (barry) wrote : | # |
On Jul 14, 2015, at 12:33 PM, Michael Vogt wrote:
>And finally - python3 seems to be not have a official linux binary
>download. Which is a bit of a bummer.
It's pretty much impossible to provide that upstream, given the wide range of
ABI differences among the Linux landscape.
| Michael Terry (mterry) wrote : | # |
More comments.
| Michael Vogt (mvo) wrote : | # |
@Barry: aha, thanks! Thats useful to know :)
@Michael: Thanks a bunch for the review. I addressed the points (hopefully) and this should be ready.
| Michael Terry (mterry) wrote : | # |
A couple comments, mostly about the environment stuff.
Looks nice and clean. Encouraging, in terms of how hard it is to write plugins.
| Michael Terry (mterry) wrote : | # |
Oh hrm. I asked about testing the snap. Snapcraft's default "wrap the user's binaries in a script that sets up the environment for them" logic wouldn't find your sha3sum script, because it's not in bin/ or usr/bin/...
Now that Snapcraft will know the metadata for the snap ahead of time... Maybe it should only wrap the binaries listed in package.yaml. That way it could find them anywhere.
| Michael Vogt (mvo) wrote : | # |
Thanks for your comments, I replied inline and fixed the issues.
As for:
> Snapcraft's default "wrap the user's binaries in a script that sets up the environment for them
> logic wouldn't find your sha3sum script, because it's not in bin/ or usr/bin/...
I copy the sha3sum.py into bin/ in the copy-plugin branch now. I think the idea to only wrap stuff that is mentioned in binaries in package.yaml is great.
| Michael Terry (mterry) wrote : | # |
OK, looks nice. :)
Here's what I found out about import paths: Ubuntu's version of python (and maybe upstream's too?) looks at where it's running from to figure out it's prefix. And installs a bunch of standard import locations into sys.path.
I had a hard time believing your imports were working ("PYTHONPATH=
Here's what sys.path looks like with NO extra variables set (besides PATH to find python2 in the first place):
['/apps/
So... I think we don't need ANY of the env() lines in this branch. PATH is automatically done for bin and usr/bin by snapcraft. PYTHONHOME and PYTHONPATH are automatically discovered by python.
So that's nice...!
So I guess drop the env() bits and I'm good with this branch. I can later propose my python2 version (which is largely a copy/paste).
Ideally the python3-project plugin would also get all dependencies listed in requirements.txt or in setup.py and install them into the same part. But that can come along with the pip3 plugin (similar logic I'm guessing).
| Michael Vogt (mvo) wrote : | # |
Thanks a lot Mike for digging into the details of this. Thats indeed great news. I removed them all now (except for PATH).
| Michael Terry (mterry) wrote : | # |
Nice! :) Setting PATH can also be left out, since snapcraft core does the standard PATH locations (bin and usr/bin) for all the parts. But it's harmless.
| Michael Terry (mterry) wrote : | # |
This needs a commit message and I also noticed one thing! You still have snapFiles, when you want snap_files now.
| Michael Terry (mterry) wrote : | # |
And pullBranch is now pull_branch
| Michael Vogt (mvo) wrote : | # |
Thanks again. I fixed snap_files() in r87 and removed setting PATH along the way.
- 87. By Michael Vogt on 2015-07-17
-
fix snapFiles-
>snap_files and remove env() complettely (snapcraft sets this already). Thanks mterry! - 88. By Michael Vogt on 2015-07-17
-
merged lp:snapcraft and renamed pullBranch -> pull_branch


Spongeshaker is such a good project name. :)
I think it makes sense to have a "python3-project" plugin for setup.py-style projects.
And it probably makes sense to also have a "pip3" (or pypi3?) plugin for the use case of using the parts list as dependencies for your own project. I'm also not 100% on whether that's better or worse than "source: pip:spongeshaker"
As for the layout... I think it does make sense to offer a simple "copy" or "files" plugin. Could take a map of input files to output path?
I bet the snapcraft.yaml for your example project COULD look like:
"""
parts:
spongeshaker:
plugin: pip3
project:
plugin: copy
files:
sha3sum.py: sha3sum
snappy-metadata: meta
"""
(Uses some concepts from my recent "discussion items" email.) How does that feel?
And as for how to get python3... Maybe we could use the ubuntu package? But getting it and building it from upstream is also pretty nice if it's not too bad. Does it have many dependencies?
A couple small comments inline too.