Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
Hi.
Olivier Berger writes:
> Hi.
>
> I'm working on rdflib whose setup.py comes with :
> entry_points = {
> 'console_scripts': [
> 'rdfpipe = rdflib.tools.rdfpipe:main',
> 'csv2rdf = rdflib.tools.csv2rdf:main',
> 'rdf2dot = rdflib.tools.rdf2dot:main',
> 'rdfs2dot = rdflib.tools.rdfs2dot:main',
> 'rdfgraphisomorpishm = rdflib.tools.graphisomorphism:main',
> ],
>
> So, when building with pybuild with Python2 and Python3, these are
> installed in 2 sets of scripts in each package's /usr/bin/ and only
> differ on their respective shebang.
>
> Lintian detects the conflict OK (binaries-have-file-conflict) but it
> isn't clear to me how to resolve this.
>
> Should I add a python-rdflib-tools package (depending on either versions
> of python-rdflib or python3-rdflib ?), and then avoid installing
> the Python3 version by using a
> PYBUILD_INSTALL_ARGS_python3=--install-scripts=... and some .pyremove ?)
>
> I though maybe of another option, which is to install in each package's
> /usr/share/python[3]-rdflib/tools and only add symlinks for one of the
> packages...
>
> Is there a best practice in this case ?
>
I have seen the answers you provided, thank you.
Also, I forgot to mention that the generated scripts look like the
following :
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'rdflib==4.0.1','console_scripts','csv2rdf'
__requires__ = 'rdflib==4.0.1'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('rdflib==4.0.1', 'console_scripts', 'csv2rdf')()
)
... which leads to problems with (recursive) dependencies mentioned in the
.egg-info that may not be satisfied in Debian :-/
And also, the original rdflib/tools/*.py modules don't have a sheebang
on first line, which prevents a direct symlink option from /usr/bin/...
So... after various experiments, I think I'll go this way :
- get rid of these scripts installed through eazy_install
- add a python-rdflib-tools package that contains shell scripts of the
form :
#!/bin/sh
exec /usr/bin/python -m rdflib.tools.csv2rdf $*
- make this package depend on python-rdflib | python3-rdflib
Thus, I hope we have something basic which works in most cases (I hope I
haven't overlooked some details).
I wonder if this would sound reasonable to add a feature to dh-python or
pybuild so that such "conversions" of 'console_scripts' could be done
automatically...
Comments/remarks much welcome.
Best regards,
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvptj856@inf-8660.int-evry.fr
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
* Olivier Berger , 2013-12-16, 13:24: - add a python-rdflib-tools package that contains shell scripts of the form : #!/bin/sh exec /usr/bin/python -m rdflib.tools.csv2rdf $* I can't see how that's better than a script with #!/usr/bin/python shebang... - make this package depend on python-rdflib | python3-rdflib /usr/bin/python can't use the modules shipped by python3-rdflib. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216124159.ga5...@jwilk.net
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
Jakub Wilk writes: > * Olivier Berger , 2013-12-16, 13:24: >>- add a python-rdflib-tools package that contains shell scripts of the >>form : >> >> #!/bin/sh >> >> exec /usr/bin/python -m rdflib.tools.csv2rdf $* > > I can't see how that's better than a script with #!/usr/bin/python > shebang... > Well... it's essentially easier than altering the modules to provide them with a sheebang, making them executable and shipping symlinks... whose targets wouldn't be the same in the v2 and v3 package... >>- make this package depend on python-rdflib | python3-rdflib > > /usr/bin/python can't use the modules shipped by python3-rdflib. > Ah, thanks for spotting this... I thought it was a bit too easy indeed ;) Hmmm... Maybe this is better : #!/bin/sh /usr/bin/python3 -c 'import rdflib.tools.csv2rdf' 2>/dev/null if [ "$?" = "0" ] then exec /usr/bin/python3 -m rdflib.tools.csv2rdf $* else exec /usr/bin/python -m rdflib.tools.csv2rdf $* fi What do you think ? Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo0hj5ln@inf-8660.int-evry.fr
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
On Mon, Dec 16, 2013 at 14:19:32 +0100, Olivier Berger wrote: > Jakub Wilk writes: > > > * Olivier Berger , 2013-12-16, 13:24: > >>- add a python-rdflib-tools package that contains shell scripts of the > >>form : > >> > >> #!/bin/sh > >> > >> exec /usr/bin/python -m rdflib.tools.csv2rdf $* > > > > I can't see how that's better than a script with #!/usr/bin/python > > shebang... > > > > Well... it's essentially easier than altering the modules to provide > them with a sheebang, making them executable and shipping > symlinks... whose targets wouldn't be the same in the v2 and v3 > package... > > >>- make this package depend on python-rdflib | python3-rdflib > > > > /usr/bin/python can't use the modules shipped by python3-rdflib. > > > > Ah, thanks for spotting this... I thought it was a bit too easy indeed > ;) > > Hmmm... Maybe this is better : > > #!/bin/sh > > /usr/bin/python3 -c 'import rdflib.tools.csv2rdf' 2>/dev/null > if [ "$?" = "0" ] > then > exec /usr/bin/python3 -m rdflib.tools.csv2rdf $* > else > exec /usr/bin/python -m rdflib.tools.csv2rdf $* > fi > > What do you think ? > FWIW I think it's terrible and you should just pick one, and ship that. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216132452.gb6...@crater1.logilab.fr
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
On Dec 16, 2013, at 02:24 PM, Julien Cristau wrote: >FWIW I think it's terrible and you should just pick one, and ship that. "pick one" meaning, ship the Python 3 version. :) -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216094512.1fb01...@anarchist.wooz.org
Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto
I don't want to start a wiki war, but I'm not entirely happy with this
change. I see that Piotr reverted part of it, but I want to revert the
removal of the d/rules stanza. It's fine to have a link to the pybuild page,
and maybe we don't need the duplication, but I want LibraryStyleGuide to be a
one-stop shop for opinionated best practices for packaging (the most common)
Python stuff for Debian.
Federico, if you're on this list, can you explain why you made this change?
Was it just to reduce duplication with the pybuild page?
Cheers,
-Barry
Begin forwarded message:
Date: Sun, 15 Dec 2013 17:11:35 -
From: Debian Wiki
To: Debian Wiki
Subject: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Debian Wiki" for change
notification.
The "Python/LibraryStyleGuide" page has been changed by FedericoCeratto:
https://wiki.debian.org/Python/LibraryStyleGuide?action=diff&rev1=32&rev2=33
You'll want to have at least the following build dependencies:
* debhelper (>= 8)
- * dh-python
* python-all (>= 2.6.6-3~)
* python-setuptools
* python3-all
* python3-setuptools
- The {{{dh-python}}} dependency gets you {{{pybuild}}}. The {{{python3-all}}}
dependency is necessary if you're also going to build a Python 3 version, but
you can drop that if upstream doesn't
[[https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef|support Python
3]] yet.
+ The {{{python3-all}}} dependency is necessary if you're also going to build a
Python 3 version, but you can drop that if upstream doesn't
[[https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef|support Python
3]] yet.
+
+ And optionally:
+
+ * dh-python
+
+ The {{{dh-python}}} dependency gets you {{{pybuild}}}.
Some other build dependencies you might want:
@@ -95, +100 @@
== debian/rules ==
+ The configuration depends on the build system of choice.
+ See [[Python/Pybuild|pybuild]] for pybuild.
- Here is a {{{debian/rules}}} file for you to start with. First, I'll show
you the whole thing, then I'll explain it line by line.
-
- {{{
- #!/usr/bin/make -f
-
- #export DH_VERBOSE=1
- export PYBUILD_NAME=foo
-
- %:
- dh $@ --with python2,python3 --buildsystem=pybuild
- }}}
-
- The file starts with the standard {{{#!}}} line. I like adding the
(commented out when uploading) {{{DH_VERBOSE}}} line because it can make build
problems easier to debug.
-
- The next line is:
-
- {{{
- export PYBUILD_NAME=foo
- }}}
-
- pybuild supports a number of variables which can be used to control such
things as the destination directory for build artifacts for both the Python 2
and Python 3 builds. The defaults generally do the right thing, but you do
need to at least tell pybuild the name of your package. Here, we're telling it
that the name is {{{foo}}}. This should match the module name, so for example,
in enum34, you'd see:
-
- {{{
- export PYBUILD_NAME=enum34
- }}}
-
- even though the binary packages that get produced are {{{python-enum34}}} and
{{{python3-enum34}}}.
-
- The next line is the standard debhelper-based catch-all rule which is used to
get the whole build started:
-
- {{{
- %:
- dh $@ --with python2,python3 --buildsystem=pybuild
- }}}
-
- What's important to note here is that both of the {{{dh_python2}}} and
{{{dh_python3}}} helpers are being invoked, and also that the ''build system''
that dh will use is pybuild. There's a lot of magic packed into this line, and
the pybuild manpage goes into more detail, but essentially what this does is:
-
- * Builds the Python 2 package for all supported Python 2 versions.
- * Builds the Python 3 package for all supported Python 3 versions.
- * Automatically detects the command to run the test suite.
- * Runs the Python 2 test suite.
- * Runs the Python 3 test suite.
-
- Once all that's done, it properly installs all the files into binary packages.
-
- If your package has Sphinx documentation, add the {{{sphinxdoc}}} helper like
so:
-
- {{{
- %:
- dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
- }}}
-
- If upstream does not yet support Python 3, omit the {{{python3}}} helper for
now.
-
- And that's it! You usually won't need {{{debian/python-foo.install}}} or
{{{debian/python3-foo.install}}} files even if you have multiple binary
packages, because again, pybuild does the magic for you. You might need these
if there are some non-standard installation tricks you need to implement.
== debian/*.links ==
@@ -158, +110 @@
{{{
usr/share/doc/python-foo/html/_sources usr/share/doc/python-foo/rst
}}}
-
- == debian/*.pyremove ==
-
- Upstream source may install some files that you don't care about including in
your Debian packages. The way to handle this is by adding
{{{debian/python-foo.pyremove}}} and {{{debian/python3-foo.pyremove}}} files.
For example:
-
- {{{
- foo/conf.py
- foo/README.rst
- foo
svn error
Hello, My svn is rusty, how do I resolve the following error? # svn-buildpackage --svn-tag-only Complete layout information: buildArea=/home/brian/tree/debian/build-area origDir=/home/brian/tree/debian/tarballs trunkDir=/home/brian/tree/debian/django-ajax-selects trunkUrl=svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/trunk Starting ssh connection.. W: tagsUrl not specified anywhere, looking in the local repository... Looking in SVN for: Repository lookup, probing 'svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags' ... Repository lookup, probing 'svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1' ... Tagging django-ajax-selects (1.3.3-1) svn -m [svn-buildpackage] Tagging django-ajax-selects 1.3.3-1 cp . svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1 svn: Commit failed (details follow): svn: '/packages/django-ajax-selects/tags/1.3.3-1/debian/patches/update_urls' is out of date Command ' svn -m [svn-buildpackage] Tagging django-ajax-selects 1.3.3-1 cp . svn+ssh:// b...@svn.debian.org/svn/python-modules/packages/django-ajax-selects/tags/1.3.3-1' failed in '/home/brian/tree/debian/django-ajax-selects', how to continue now? [Qri?]: debian/patches/update_urls is a file that was deleted in this version. Also feel free to consider this a request to move to git :-) Thanks -- Brian May
