Op 17-03-12 10:02, Simon Sapin schreef:

Le 15/03/2012 15:04, Simon Sapin a écrit :

...

Hi,

Please remove 'python2-weasyprint' and 'python-weasyprint' or merge them into 'weasyprint'.

https://aur.archlinux.org/packages.php?ID=57201 https://aur.archlinux.org/packages.php?ID=57205 https://aur.archlinux.org/packages.php?ID=57621

The later installs for both Python 2 and 3. I think that a single package is less confusing, and it avoids the conflict in /usr/bin

WeasyPrint can be used from the command line or as a Python library. Unlike pip for example, users of the command-line executable do not care which version of Python is used, so having multiple versioned executables in /usr/bin/ is not useful. As a library however, users will want one Python version or the other. Do you have suggestion for packaging in such cases?

Also, please remove python3-decorator. python-decorator (for python 3) and python2-decorator are now both in "community".

https://aur.archlinux.org/packages.php?ID=57204

deleted, thx

Oh, I see I didn’t write with the same email address as my AUR account. I changed it there so you can see I’m the same person.

Regards,

It seems you did write it with the same email :p the weasyprint stuff i would rather like python-weasyprint and python2-weasyprint so there is a clear distinction you could make them not conflicting by having /usr/bin/weasyprint2 in the python2-weasyprint package maybe some other tu could give some input here, thx -- Ike

Op 17-03-12 11:03, Simon Sapin schreef:

Le 17/03/2012 10:30, Ike Devolder a écrit :

...

the weasyprint stuff i would rather like python-weasyprint and python2-weasyprint so there is a clear distinction

you could make them not conflicting by having /usr/bin/weasyprint2 in the python2-weasyprint package

As I said in my first email, /usr/bin/weasyprint2 would do exactly the same as /usr/bin/weasyprint (if they don’t it’s a bug) so there is no point in having both. It also looks like version 2 of weasyprint, which it is not.

Currently python2-weasyprint does not install anything in /usr/bin, but that’s probably not the best solution.

if the part sitting in /usr/bin is working with both the python2 and python3 libs i would suggest the following: python2-weasyprint (python2 lib) (providing python-weasyprint) python-weasyprint (python3 lib) weasyprint (the commandline tool) (depending on python-weasyprint) so weasyprint should be able to work with either one of the libs installed -- Ike

Op 17-03-12 11:27, Simon Sapin schreef:

Le 17/03/2012 11:15, Ike Devolder a écrit :

...

if the part sitting in /usr/bin is working with both the python2 and python3 libs i would suggest the following

It does not. Distribute creates files with a shebang of whatever python executable was used to run setup.py, eg:

#!/usr/bin/python2

We could make instead a shell script that checks at run-time which version is installed, but is it really worth it?

in my oppinion it is worth it, there are people around who dont want any python3 stuff on their pc until they can move everything now your weasyprint combined package pulls a lot of stuff, it is simple in a way that it will always work but you have a *lot* of overhead there so personally i would consider the following: - have python-weasyprint with renamed binary python-weasyprint - have python2-weasyprint with renamed binary python2-weasyprint - have weasyprint with only a binary weasyprint which can start any of the previous *or* - have python-weasyprint only with libs, no binary - have python2-weasyprint only with libs, no binary - have weasyprint which can 'decide' which of the above is installed and run it with /usr/bin/python or /usr/bin/python2 attached a possibility to switch to the installed version -- Ike

Op 18-03-12 12:07, Simon Sapin schreef:

Le 17/03/2012 18:52, Ike Devolder a écrit :

...

in my oppinion it is worth it, there are people around who dont want any python3 stuff on their pc until they can move everything now your weasyprint combined package pulls a lot of stuff, it is simple in a way that it will always work but you have a*lot* of overhead there

Ok I can understand that.

...

so personally i would consider the following:

- have python-weasyprint with renamed binary python-weasyprint - have python2-weasyprint with renamed binary python2-weasyprint - have weasyprint with only a binary weasyprint which can start any of the previous

Again, I don’t think multiple binaries are useful.

...

*or*

- have python-weasyprint only with libs, no binary - have python2-weasyprint only with libs, no binary - have weasyprint which can 'decide' which of the above is installed and run it with /usr/bin/python or /usr/bin/python2

attached a possibility to switch to the installed version

python{,2}-weasyprint packages with only libs sound good. I only use it as a lib myself; I added the command-line interface because it was easy. Actually, it’s probably better to have a long-lived python process than to pay the start-up cost every time, even in a non-python application.

As for the third package, would it depend on one or the other lib package?

i would have weasyprint depend on python-weasyprint and have python2-weasyprint provide python-weasyprint so then you can have a choice and provide maximum flexibility

I found two patterns in existing packages in [community]:

* python-pygments just removes /usr/bin/pygmentize (python2-pygments has it)

it is also an option but it reduces somewhat the flexibility

* python2-sphinx renames eg. /usr/bin/sphinx-build to sphinx-build2, but I guess it could be important to have both if Sphinx need to import the documented code.

the renaming you had rejected previously in this thread so i did not bring it back in. renaming can have a drawback for other binaries or scripts depending on your binary name, which would imply a change into those packages too.

Regards,

-- Ike

Op 18-03-12 12:53, Simon Sapin schreef:

Le 18/03/2012 12:42, Ike Devolder a écrit :

...

i would have weasyprint depend on python-weasyprint and have python2-weasyprint provide python-weasyprint

Right. I didn’t think about the "provide" mechanism. I’ll update the packages and see how this works.

I can’t help but want the two packages to install the same file (both name and content) and have the file stay as long as at least one of the packages is installed. That would require pacman to have some kind of reference counting, but that’s probably too much :)

I thank that emerge (for Gentoo) special cases python executables. Users can choose in their config which python versions they want to install, and which is their "favorite". emerge creates executables with version suffixes like -2.7, and a symlink without suffix for the "favorite" version. The symlink is managed by emerge itself, not each package.

If this kind of conflict in /usr/bin becomes recurrent, should such a mechanism be considered for pacman?

for this you could file a feature request in the bugtracker [1] with this example so it is clear what you suggest. [1] https://bugs.archlinux.org/index.php?project=3&do=index&switch=1

Regards,

-- Ike

Le 18/03/2012 12:42, Ike Devolder a écrit :

...

...

I guess it could be important to have both if Sphinx need to import the documented code.

* python2-sphinx renames eg. /usr/bin/sphinx-build to sphinx-build2, but the renaming you had rejected previously in this thread so i did not bring it back in.

I went with this solution. python2-weasyprint now renames /usr/bin/weasyprint to /usr/bin/weasyprint2. Please remove the 'weasyprint' package: https://aur.archlinux.org/packages.php?ID=57621 I did initially reject this, but on further thought I guess it is the lesser of all "evils".

renaming can have a drawback for other binaries or scripts depending on your binary name, which would imply a change into those packages too.

This is a young project, and the AUR packaging is even more recent. I doubt anything relies on the python2 package installing a script with a particular name. Thanks, -- Simon Sapin