On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
I really do like this. There are only two issues I have with it:
- 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.
- 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.