Merge lp://qastaging/~sergiusens/snapcraft/ubuntu-core into lp://qastaging/~snappy-dev/snapcraft/core
Proposed by
Sergio Schvezov
| Status: | Merged |
|---|---|
| Approved by: | Michael Vogt |
| Approved revision: | 163 |
| Merged at revision: | 154 |
| Proposed branch: | lp://qastaging/~sergiusens/snapcraft/ubuntu-core |
| Merge into: | lp://qastaging/~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://qastaging/~sergiusens/snapcraft/ubuntu-core |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Vogt (community) | Approve | ||
|
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.
To post a comment you must log in.
Revision history for this message
| Ted Gould (ted) wrote | # |
Revision history for this message
| Leo Arias (elopio) wrote | # |
Revision history for this message
| Sergio Schvezov (sergiusens) wrote | # |
Revision history for this message
| Michael Vogt (mvo) wrote | # |
Revision history for this message
| Sergio Schvezov (sergiusens) wrote | # |
Revision history for this message
| Sergio Schvezov (sergiusens) | # |
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
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 :-)