[aur-general] [REVIEW REQUEST] python-viivakoodi

[Eli Schwartz]

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