On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com> wrote:
> I really do like this. There are only two issues I have with it:
>
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
>
> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> people who release Go code as tarballs (it's rare, but it happens).
> How do you deal with that?
By not using the macros for packages not fitting the model?
The issue is that the new Go macros are tightly wound into the forge
macros. I just want to be sure that we can leverage things like the
dependency generators without all the other stuff.
I think this is very helpful especially when it's the common
practice,
and I certainly won't blame anyone doing proper releases and not
just a git tag with github releases notes ;)
Regarding naming, I think python packages must be prefixed with
python[23]- and can Provides: the upstream project name. On the
other hand we have packages like docker that are clearly named
after upstream's name, so I don't think that would be a problem for
snapd. (and maybe an exception needs to be granted?)
This rule only applies to Python packages that have modules that are
designed to be imported by other Python code. Otherwise, this is not
necessary.
--
真実はいつも一つ!/ Always, there's only one truth!