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

Wed Nov 30 01:19:29 UTC 2016

On 16-11-28 23:02:02, Eli Schwartz via aur-general wrote:
> 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.
Ouch, one new try :p

> 
> Sorry, this must seem quite confusing with all this back and forth. :D
> On the other hand, think of everything you are learning...
Definitely, but its quiet fun to be faced with such problems. If you
may I propose the following summary in order to assert that I am
starting to get a bigger picture:

- setuptools related stuff
Some project, like viivakoodi, needs setuptools for installation. In
such case pythonX-setuptools is needed at build-time.
  * If we provide a split packages both python{,2}-setuptools should
  be included into makedepends()
  * If the project use *console_scripts* entry points
  pythonX-setuptools is needed as the runtime dependencies too. 

- PKGBUILD/makepkg related stuff
At built-time makepkg "merge" both makedepends() and depends().
  * However, if we are building a split package with a depends()
  inside a package_* function, this depends() will not be watched at
  built-time. So packager must "copy" the content of package_*
  depends() into global makedepends() in that particular case.

> > 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
-------------- next part --------------
# Maintainer: Quentin Bourgeois <quentin+archlinux at bourgeois.eu>

pkgbase=viivakoodi
pkgname=("python2-${pkgbase}" "python-${pkgbase}")
pkgver=0.8.0
pkgrel=1
pkgdesc='Barcode generator for Python. Fork of pyBarcode project.'
arch=('any')
url="https://github.com/kxepal/${pkgbase}"
license=('MIT')
source=("${pkgbase}-${pkgver}.tar.gz::${url}/archive/${pkgver}.tar.gz")
sha256sums=('e1a17dc24975d5242202cfbb7534d69dd14eeb26bdf8a10f056c7b04904fef1e')
makedepends=('python-setuptools'
             'python2-setuptools')

check() {
    cd "${srcdir}/${pkgbase}-${pkgver}"
    
    for py_int in python3 python2; do
        msg "Testing ${pkgbase}-${pkgver} with ${py_int}"
        "${py_int}" ./test.py
    done
}

package_python-viivakoodi() {
    depends=('python-setuptools')
    optdepends=('python-pillow: render barcodes as images')
    checkdepends=('python-pytest'
                  'python-mock'
                  'python-tox')
    cd "${srcdir}/${pkgbase}-${pkgver}"
    python setup.py install --root="${pkgdir}/" --optimize=1

    install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE.launcher"
}

package_python2-viivakoodi() {
    depends=('python2-setuptools')
    optdepends=('python2-pillow: render barcodes as images')
    checkdepends=('python2-pytest'
                  'python2-mock'
                  'python2-tox') 

    cd "${srcdir}/${pkgbase}-${pkgver}"
    python2 setup.py install --root="${pkgdir}/" --optimize=1

    install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE.launcher"
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161130/99b463ac/attachment-0001.asc>