Removing sub-parts from the remote parts ecosystem.

[Didier Roche]

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?

Also, please do not break this feature before the parts are transitioned
to the new name scheme.

My 2 cents
Didier