Merge lp:~sergiusens/snapcraft/ubuntu-core into lp:~snappy-dev/snapcraft/core
| Status: | Merged |
|---|---|
| Approved by: | Michael Vogt on 2015-09-09 |
| Approved revision: | 163 |
| Merged at revision: | 154 |
| Proposed branch: | lp:~sergiusens/snapcraft/ubuntu-core |
| Merge into: | lp:~snappy-dev/snapcraft/core |
| Diff against target: |
1062 lines (+306/-369) 28 files modified
debian/control (+0/-1) examples/webcam-webui-snap/snapcraft.yaml (+2/-2) examples/wget-deb/snapcraft.yaml (+0/-12) integration-tests/data/assemble/snapcraft.yaml (+1/-1) plugins/ant-project.yaml (+1/-0) plugins/autotools-project.yaml (+8/-7) plugins/cmake-project.yaml (+1/-0) plugins/copy.yaml (+1/-1) plugins/go-project.yaml (+1/-0) plugins/make-project.yaml (+1/-0) plugins/maven-project.yaml (+1/-0) plugins/python2-project.yaml (+1/-0) plugins/python3-project.yaml (+1/-0) plugins/tar-content.yaml (+1/-0) plugins/ubuntu.yaml (+0/-6) schema/snapcraft.yaml (+9/-3) setup.py (+1/-1) snapcraft/__init__.py (+13/-0) snapcraft/plugin.py (+21/-4) snapcraft/plugins/jdk.py (+6/-16) snapcraft/plugins/python2.py (+3/-16) snapcraft/plugins/python3.py (+3/-16) snapcraft/plugins/qml.py (+40/-53) snapcraft/plugins/tests/test_ubuntu.py (+0/-61) snapcraft/plugins/ubuntu.py (+0/-132) snapcraft/repo.py (+132/-0) snapcraft/tests/test_repo.py (+38/-22) snapcraft/tests/test_yaml.py (+20/-15) |
| To merge this branch: | bzr merge lp:~sergiusens/snapcraft/ubuntu-core |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Vogt | 2015-09-02 | Approve on 2015-09-09 | |
|
Review via email:
|
|||
Commit Message
Replace Ubuntu plugin with a builtin solution
Description of the Change
This completely removes the Ubuntu plugin and introduces stage-packages for
both plugins and parts in one big bundle.
I'm not sure the big bundle is the best solution, but if required a plugin author could use repo.Ubuntu directly and independently from what a part does.
This is missing complete feature parity as the get_snap_files equivalent is missing and coming with filtering implementation exposed in the part.
As you can see, this model invalidates the wget example because it is a 1:1 conversion and nothing else, not sure if this was the desired outcome from the proposal.
- 155. By Sergio Schvezov on 2015-09-02
-
Making PLUGIN_
STAGE_PACKAGES private so isbaseclass in the plugin loader doesn't get all confused - 156. By Sergio Schvezov on 2015-09-02
-
merging trunk
- 157. By Sergio Schvezov on 2015-09-02
-
stage-package for parts and plugins separation of concerns
| Ted Gould (ted) wrote : | # |
- 158. By Sergio Schvezov on 2015-09-04
-
pull stage packages before pulling the code
- 159. By Sergio Schvezov on 2015-09-04
-
cleanup
| Leo Arias (elopio) wrote : | # |
Just a couple of comments on the diff.
And a question: how would you build a deb into a snap?
| Sergio Schvezov (sergiusens) wrote : | # |
> And a question: how would you build a deb into a snap?
The simple answer, which may support the third paragraph in the description, is that the new design doesn't allow for a 1:1 translation, so snaps based out of pure ubuntu packages are not allowed but instead used to support greater snaps.
- 160. By Sergio Schvezov on 2015-09-07
-
minor elopio improvement
| Michael Vogt (mvo) wrote : | # |
Thanks, this looks good! I have some inline comments, but nothing that blocks this from landing, a mix of nitpick and ideas for improvement. I like the idea of running it before pull and to allow the plugins to override it.
| Sergio Schvezov (sergiusens) wrote : | # |
@mvo, thanks for the review, I'll look into addressing your comments
- 161. By Sergio Schvezov on 2015-09-07
-
Simplifying __init__ for plugins and stage packages
- 162. By Sergio Schvezov on 2015-09-07
-
making manifest.txt useful again
- 163. By Sergio Schvezov on 2015-09-08
-
Merging trunk


I've been playing with this for the Python PIP case, and I think it gets
a little confusing. The problem is that for the PIP case we need to have
the packages installed before we can use them to download the packages
from the PIP repository. So by specifying the packages we can't then use
PIP in the pull phase for the plugin. The reason that we need to be in
the pull phase is that we want to be the stage that everything is
downloaded in, which clearly PIP does a fair amount of.
I also think that we need to maintain the package list as a singleton in
the core of snapcraft as if two parts want to use the same Ubuntu
package, that should be fine, but we can't install both of them into the
snap. This gets complicated with multiple repositories (having one part
and set of deps that are built on one distro version and another on a
different version; complicated but something that'll probably happen
when people use the wiki entries) but I think the singleton can handle
this by installing them to different directories in that case.
I think that this architecture means that also we can effectively create
a virtual dependency for each plugin that uses Ubuntu packages, so that
it can run all of its phases after the Ubuntu plugin installs its
packages. In that way the other plugins can use the packages that are
installed to evaluate their own phases.
I'm a little concerned with the idea that we'd install the packages
before running the pull phases of the other plugins. I think that this
creates a scenario where we can't do all the downloads in one phase.
This is a traditional setup for the builders to limit exposure to user
delivered code, so they can turn off networking while things are
building. But, I don't see a way around that. I think we'll have to have
that conversation with the LP folks as it comes along. We may have to
provide a "virtual" ubuntu plugin for non-Ubuntu repositories so that
the only execution before pull are done with packages in the official
repos. But, I don't think we need to solve that problem today :-)