Installing python modules in a non-standard way

[Onur Aslan]

Hi. I asked this in IRC channel but didn't get a clear answer.

I have a library package written in C and it's also providing
python wrappers.

You can see the package in here:
https://anonscm.debian.org/cgit/collab-maint/gumbo-parser.git/

I can't use --buildsystem=pybuild to install python wrappers,
this package is not providing a configure script or Makefile. pybuild
is not invoking autoreconf to generate a configure script. I have
to build C library manually if I use pybuild buildsystem
for this package.

I've been using $(py3versions -rv debian/control) in
override_dh_auto_install to install python3 package. But since
python3-all became depended on python3.4 and python3.5,
py3versions started to return two python versions and my override
is no longer working.

I decided to use $(py3versions -d) but I am not sure this is good
idea. It's skipping X-Python3-Version defined in d/control.

Piotr suggested me to make a loop to install python3.4 and python3.5
versions of package. But is it really necessary?

I am wondering what is proper way to install python modules in this
package?

Re: Installing python modules in a non-standard way

[Andrey Rahmatullin]

On Sun, Oct 25, 2015 at 10:37:13AM +0200, Onur Aslan wrote:
> I can't use --buildsystem=pybuild to install python wrappers,
> this package is not providing a configure script or Makefile. pybuild
> is not invoking autoreconf to generate a configure script. I have
> to build C library manually if I use pybuild buildsystem
> for this package.
Nothing is invoking autoreconf unless you use --with autoreconf. Are you
saying that with pybuild this option has no effect?

> Piotr suggested me to make a loop to install python3.4 and python3.5
> versions of package. But is it really necessary?
If you want to install modules for all supported versions then yes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Installing python modules in a non-standard way

[Ben Finney]

Onur Aslan  writes:

> I can't use --buildsystem=pybuild to install python wrappers, this
> package is not providing a configure script or Makefile. pybuild is
> not invoking autoreconf to generate a configure script.

Can you add a target to ‘debian/rules’ that will invoke ‘autoreconf’, as
a pre-requisite for the ‘override_dh_build’ target?

> Piotr suggested me to make a loop to install python3.4 and python3.5
> versions of package.

I don't use a loop, but rather a pattern-matching target and a Makefile
substitution variable to generate targets for all the supported Python
versions. It amounts to the same result, but is not “a loop”.

> But is it really necessary?

In the absence of Pybuild, yes I've found that explicitly making
separate targets for each supported Python version is necessary. This is
one of the main benefits of migrating to Pybuild.

> I am wondering what is proper way to install python modules in this
> package?

My suggestion: work hard to get the package to provide what Pybuild
needs, and let Pybuild do its job from there.

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)development, 2002 |
Ben Finney

Re: Installing python modules in a non-standard way

[Andrey Rahmatullin]

On Sun, Oct 25, 2015 at 12:39:44PM +0200, Onur Aslan wrote:
> > Nothing is invoking autoreconf unless you use --with autoreconf. Are you
> > saying that with pybuild this option has no effect?
> 
> I am already using --with autoreconf but when I use:
> 
> dh $@ --with autoreconf,python2,python3 --buildsystem=pybuild
> 
> It's running autoreconf to generate configure script and thats all.
> It's not running ./configure or make to build library.
Indeed.
In this case I'd use the usual autotools buildsystem and do everything
else manually, without using pybuild. But maybe there are better options.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Installing python modules in a non-standard way

[Onur Aslan]

On 2015-10-05,  Andrey Rahmatullin wrote:
> Nothing is invoking autoreconf unless you use --with autoreconf. Are you
> saying that with pybuild this option has no effect?

I am already using --with autoreconf but when I use:

dh $@ --with autoreconf,python2,python3 --buildsystem=pybuild

It's running autoreconf to generate configure script and thats all.
It's not running ./configure or make to build library.

'dh_auto_configure -O--buildsystem=pybuild' is skipping ./configure
and only configuring python modules. I believe if I use
--buildsystem=pybuild I have to configure and build C library
manually. That is the reason I want to avoid pybuild in this package.

You can see full build log in attached file.
dpkg-buildpackage: source package gumbo-parser
dpkg-buildpackage: source version 0.10.1+dfsg-3
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Onur Aslan 
 dpkg-source --before-build gumbo-parser
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh clean --with autoreconf,python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/onur/code/debian/libgumbo/gumbo-parser'
dh_auto_clean
pybuild --clean -i python{version} -p 2.7 --dir .
I: pybuild base:170: python2.7 setup.py clean 
running clean
removing 
'/home/onur/code/debian/libgumbo/gumbo-parser/.pybuild/pythonX.Y_2.7/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
pybuild --clean -i python{version} -p "3.5 3.4" --dir .
I: pybuild base:170: python3.5 setup.py clean 
running clean
removing 
'/home/onur/code/debian/libgumbo/gumbo-parser/.pybuild/pythonX.Y_3.5/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.5' does not exist -- can't clean it
I: pybuild base:170: python3.4 setup.py clean 
running clean
removing 
'/home/onur/code/debian/libgumbo/gumbo-parser/.pybuild/pythonX.Y_3.4/build' 
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't clean it
rm -rf .pybuild/
find . -name \*.pyc -exec rm {} \;
rm -f -rfv build/
rm -f -rfv docs/
rm -f -rfv python/gumbo.egg-info/
removed ‘python/gumbo.egg-info/not-zip-safe’
removed ‘python/gumbo.egg-info/PKG-INFO’
removed ‘python/gumbo.egg-info/SOURCES.txt’
removed ‘python/gumbo.egg-info/dependency_links.txt’
removed ‘python/gumbo.egg-info/top_level.txt’
removed directory: ‘python/gumbo.egg-info/’
rm -f -rfv Makefile.in aclocal.m4 compile config.guess config.sub \
   configure depcomp install-sh ltmain.sh m4/ missing test-driver
removed ‘Makefile.in’
removed ‘aclocal.m4’
removed ‘compile’
removed ‘config.guess’
removed ‘config.sub’
removed ‘configure’
removed ‘depcomp’
removed ‘install-sh’
removed ‘ltmain.sh’
removed ‘m4/ltoptions.m4’
removed ‘m4/lt~obsolete.m4’
removed ‘m4/ltversion.m4’
removed ‘m4/libtool.m4’
removed ‘m4/ltsugar.m4’
removed directory: ‘m4/’
removed ‘missing’
removed ‘test-driver’
make[1]: Leaving directory '/home/onur/code/debian/libgumbo/gumbo-parser'
   dh_autoreconf_clean -O--buildsystem=pybuild
rm -f -- ./depcomp ./config.sub ./config.guess ./Makefile.in 
./configure ./install-sh ./compile ./m4/ltoptions.m4 ./m4/lt\~obsolete.m4 
./m4/ltversion.m4 ./m4/libtool.m4 ./m4/ltsugar.m4 ./aclocal.m4 ./missing 
./ltmain.sh ./test-driver ./autom4te.cache/output.1 ./autom4te.cache/output.2 
./autom4te.cache/traces.1 ./autom4te.cache/traces.2 ./autom4te.cache/traces.0 
./autom4te.cache/output.0 ./autom4te.cache/requests
rm -f debian/autoreconf.before debian/autoreconf.after
   dh_clean -O--buildsystem=pybuild
rm -f debian/libgumbo-dev.substvars
rm -f debian/libgumbo-dev.*.debhelper
rm -rf debian/libgumbo-dev/
rm -f debian/libgumbo1.substvars
rm -f debian/libgumbo1.*.debhelper
rm -rf debian/libgumbo1/
rm -f debian/python-gumbo.substvars
rm -f debian/python-gumbo.*.debhelper
rm -rf debian/python-gumbo/
rm -f debian/python3-gumbo.substvars
rm -f debian/python3-gumbo.*.debhelper
rm -rf debian/python3-gumbo/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
find .  \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path 
.\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
 -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
 -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
 -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + 

Re: Installing python modules in a non-standard way

[Dmitry Shachnev]

On Sun, Oct 25, 2015 at 04:45:17PM +0500, Andrey Rahmatullin wrote:
> Indeed.
> In this case I'd use the usual autotools buildsystem and do everything
> else manually, without using pybuild. But maybe there are better options.

Or maybe try to use both build systems, something like this:

  override_dh_auto_build:
  dh_auto_build
  dh_auto_build -O--buildsystem=pybuild

(and the same for install/clean/etc).

--
Dmitry Shachnev