On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> 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! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
