Removing sub-parts from the remote parts ecosystem.

[Joe Talbott]

On Aug 10, 2016 2:15 AM, "Didier Roche" <didrocks at ubuntu.com> wrote:
>
> Le 09/08/2016 à 23:41, Joe Talbott a écrit :
> > Dear Snapcrafters,
>
> Hey Joe,
> >
> > The wiki introduced the concept of sub-parts and used namespacing to
> > associate a list of sub-parts with a project-part.  However the
> > concept was ill-conceived and now needs to be removed.  In essence,
> > all parts should be top level parts.  Each entry in the wiki should
> > identify one or more parts from a snapcraft.yaml file that are
> > considered to be useful to other snapcraft users.  A current example
> > of subparts might look like this:
> >
> >    ---
> >    origin: https://github.com/josepht/snaptastic
> >    maintainer: Joe Talbott <joe.talbott at canonical.com>
> >    description: Some fun parts
> >    project-parts: fun-part
> >    parts: [a, b, c]
> >
> > Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and
> > ‘fun-part/c’.  The new approach should be:
> >
> >    ---
> >    origin: https://github.com/josepht/snaptastic
> >    maintainer: Joe Talbott <joe.talbott at canonical.com>
> >    description: Some fun parts
> >    parts: [fun-part, fun-part-a, fun-part-b, fun-part-c]
> >
> > Where the hierarchy is removed and each part is a top-level part.  The
> > part names will need to be changed in the snapcraft.yaml file as well.
> >
>
> Namespacing was really nice for things like desktop/ parts
> (desktop/gtk3, desktop/gtk2, desktop/qt5, desktop/qt4,
> desktop/glibonly). There is as well  mqtt-paho/python2 and
> pqtt-patho/python3.
> A lot of existing snaps are using those already and I find it really sad
> that we are going to break backward compatibility for a feature that was
> prominently advocated for in our blog posts like
> http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/.
> Developers prefer to work on their snap rather than fighting for keeping
> it working with latest snapcraft/store, please keep that in mind.
>
> I think at least a reasonable approach would be to have a transition
> plan for a period of time backed into the tool. That means that
> snapcraft needs to be able to detect namespaced parts, and suggests
> corresponding new part name to use (as we only have 7 of them, that
> seems reasonable to handle the mapping by hand). I think that will put a
> nice precedent on how we care about developer experience, and try to
> minimize the impact on everyone. Is there anything like this planned?

The plan would be to convert the wiki parts and their origins but to have a
deprecation warning for any snapcraft.yaml using the namespaced part names
and to have snapcraft automatically convert '/' to '-' during part
loading.  This should lessen the pain for developers and allow them to make
plans to update their snapcraft.yaml files.

Thanks,
Joe
>
> Also, please do not break this feature before the parts are transitioned
> to the new name scheme.
>
> My 2 cents
> Didier
>
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160810/8e6d59e9/attachment.html>