On 11/28/2016 07:47 PM, Quentin Bourgeois wrote:
On 16-11-27 19:41:06, Eli Schwartz via aur-general wrote:
On 11/27/2016 06:10 PM, Quentin Bourgeois wrote:
With this, I come with a simpler PKGBUILD[0] in which I push modifications you advised. I also removed some dependencies that are used for code coverage and building documentation, which I do not install for now.
Did we get to something good ?
[0] https://git.bourgeois.eu/aur_python_viivakoodi.git/tree/
I should comes with all modification on this batch.
Err, why do both split packages provide 'python2-viivakoodi'? One of them already is 'python2-viivakoodi', and the other by definition doesn't supply it, being Python 3. My mistake.
You declare setuptools as a makedepends only, but I hate to inform you that setuptools-installed packages have a runtime dependency on setuptools to launch their console scripts. (This is the downside of having python itself be capable of generating the entry point launchers in a cross-platform manner -- rather than using your own python scripts with file extensions, then assuming Linux users will be happy with the extension and Windows users will be able to launch a non-binary.)
For module-only python packages, it is only a makedepends... for packages which ship with console_scripts you need it at runtime as well, otherwise the console_scripts will fail trying to import pkg_resources.
You can either have each split package depend on python{,2}-setuptools, or depend on both that and the python{,2} package itself. I have seen it done both ways. Hum, this was not abvious for me, thanks. With what I have understand from that I have decide to make every split package depend on pythonX and pythonX-setuptools its seem simpler for me to understand.
I will dig this setuptools + console_script topics by my own.
Nooooo, put the combined setuptools makedepends back! makepkg usually includes depends=() in the resolved build-time dependencies, but for split packages which have depends=() declared in the package_* function, those do not get added to the build-time dependencies. You can actually use that as a practical way to define rundepends -- runtime-only depends which don't need to be installed when building (which makepkg has no concept of and the developers aren't interested in especially considering there is a reasonable workaround). So, many python packages end up with a makedepends on python{,2}-setuptools (to ensure building works) *and* a depends on setuptools in each package_* function. Sorry, this must seem quite confusing with all this back and forth. :D On the other hand, think of everything you are learning...
On this, when I run namcap on created packages I get some warnings:
$ namcap *.tar.xz python2-viivakoodi W: Dependency python2 included but already satisfied python2-viivakoodi W: Dependency included and not needed ('python2-setuptools') python-viivakoodi W: Dependency python included but already satisfied python-viivakoodi W: Dependency included and not needed ('python-setuptools')
For every packages the first warning is due to my choice. For the second does namcap could warn packager that are not aware of the setuptools+console_scripts things (or maybe its something well known ?).
Namcap is meant to offer suggestions that may or may not be applicable. It should *never* be taken as gospel truth. I am not sure how it figures out which python packages are "needed", although it usually does a pretty good job of checking shared library dependencies.
On style preferences, when I code in Bash I over use {} arround variables (mainly when variables are tied to other strings). What is the guideline on this ?
There are no guidelines, some people use them and some people don't. (Rather like bash itself, which also has its fiercely divided camps advocating competing style guides.) I myself prefer them, you are definitely not alone. :) -- Eli Schwartz