FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 03-18-2012, 10:07 AM
Simon Sapin
 
Default Merge / deletion requests: weasyprint and python3-decorator

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 found two patterns in existing packages in [community]:

* python-pygments just removes /usr/bin/pygmentize (python2-pygments has it)
* 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.


Regards,
--
Simon Sapin
 
Old 03-18-2012, 10:42 AM
Ike Devolder
 
Default Merge / deletion requests: weasyprint and python3-decorator

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
 
Old 03-18-2012, 10:53 AM
Simon Sapin
 
Default Merge / deletion requests: weasyprint and python3-decorator

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?


Regards,
--
Simon Sapin
 
Old 03-18-2012, 11:28 AM
Ike Devolder
 
Default Merge / deletion requests: weasyprint and python3-decorator

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
 
Old 03-19-2012, 10:23 AM
Simon Sapin
 
Default Merge / deletion requests: weasyprint and python3-decorator

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

* 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.



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
 
Old 03-19-2012, 11:35 AM
Simon Sapin
 
Default Merge / deletion requests: weasyprint and python3-decorator

Le 18/03/2012 13:28, Ike Devolder a crit :

for this you could file a feature request in the bugtracker [1] with
this example so it is clear what you suggest.



I just opened #29004. Discussion should probably go there:

https://bugs.archlinux.org/index.php?do=details&task_id=29004

Regards,
--
Simon Sapin
 

Thread Tools




All times are GMT. The time now is 06:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org