[...]
TL;DR
- Short answer: When viewed as incremental steps, I could be happy with this order of events, but will definitely want to implement something along the lines of this proposal around (3).
Great. Unless anyone else wants to chime in, I think we have a path forward then. Would you care to summarize one last time?
[...]
> > Once we split up the plugins into multiple domains, it means:
> >
> > * Users need to have the knowledge of plugins are required
> > communicated to them out of band, making the experience generally
> > more painful for the typical user who wants to start contributing
> > to a given project.
> >
> > While there is still names encoded in project.conf, the knowledge
> > of how to obtain these packages and where they come from is
> > still a nuisance and needs to be carried - this is much reduced
> > in the current situation where our upstream plugins live directly
> > in core, and is not immensely bad if we have all blessed plugins
> > in a single repo.
>
> This will work with local origin in combination with git submodules,
> svn externals, or mercurial subrepositories - whatever VCS the
> project has chosen.
I should point out that users don't really have VCS freedom, or am I
able to use `svn externals` in order to use a plugin repository that is
maintained in git ?
Depending on what you are using to host it, yes:
Or the project maintainer could mirror the plugins in a svn repo.
Mercurial does have subrepository support that includes git AIUI.
[...]
I expect that once we do start talking about which plugins go where, I
will find myself arguing that the essential ostree plugin is a must for
a set of blessed plugins (nothing can really build without it as the
base import, perhaps docker source is a viable alternative but
currently ostree is the default for base imports).
Tarballs also do the trick.
[...]
> I personally fail to see why we need to wait. I find the "people
> hate submodules" not enough of a technical argument. That projects
> take a decision to advise users to install plugins on their system,
> is their choice. If they think they can manage their user's base
> plugins the best way this way, then allow them to do so. If at some
> later point there is a better way,
I think this is an unfinished sentence... maybe you are alluding to the
possibility of implementing something more convenient at some point.
That was what I was alluding to with that [non-deliberate] unfinished sentence, yes :).
In any case yes I can agree with this, however I do have the opinion
that it is our responsibility to make the safest mode of operation the
most convenient one, so I am very keen on evolving the plugin origins
so that project-bound plugins are more obvious and easy to use than via
submodules.
Noted.
[...]
Cheers,
Sander
