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 Development

 
 
LinkBack Thread Tools
 
Old 09-13-2012, 08:27 PM
Florian Pritz
 
Default Python 3.3.0 and PEP 394

On 13.09.2012 22:03, Rashif Ray Rahman wrote:
> On 14 September 2012 02:18, Sébastien Luttringer <seblu@seblu.net> wrote:
>> We also have python libraries not prefixed by python- (e.g: pyalpm,
>> pycups, pygtk, etc), I think we should also update with
>> pkgbase=pygtk
>> pkgname=(python-gtk python2-gtk)
>
> That breaks common knowledge and conventional project names. This
> happened with pyqt:
>
> python2-qt
> python-qt
>
> Those look absolutely nothing like 'PyQt', which is the project name.
> We worked around this for a while using 'PyQt:' in the description so
> that it'd come up in searches for 'pyqt'. You could also provide for
> it in both, but that would still be a workaround.

python2-pyqt
python2-pygtk

The little bit of redundancy (python-py) isn't too bad IMHO and it's a
clear naming scheme without special cases.

--
Florian Pritz
 
Old 09-13-2012, 09:26 PM
Sébastien Luttringer
 
Default Python 3.3.0 and PEP 394

On Thu, Sep 13, 2012 at 10:27 PM, Florian Pritz <bluewind@xinu.at> wrote:
> On 13.09.2012 22:03, Rashif Ray Rahman wrote:
>> On 14 September 2012 02:18, Sébastien Luttringer <seblu@seblu.net> wrote:
>>> We also have python libraries not prefixed by python- (e.g: pyalpm,
>>> pycups, pygtk, etc), I think we should also update with
>>> pkgbase=pygtk
>>> pkgname=(python-gtk python2-gtk)
>>
>> That breaks common knowledge and conventional project names. This
>> happened with pyqt:

I'm not sure it's very important (and possible) to use the project
name without alteration in our package name.
As you said, the most important is to be able to find it (by a search)
with a minimum common sense.

Developer which use pyqt, will search something like:
$ pacman -Sqs pyqt4
eric
eric4
and doesn't found it. Because they may use the real name of the python
library (import PyQt4).

>>
>> python2-qt
>> python-qt
>>
>> Those look absolutely nothing like 'PyQt', which is the project name.
$pkgbase would be pyqt (or even PyQt). IIRC, archweb already display
split package by $pkgbase in "Recent Updates".

https://www.archlinux.org/packages/community/x86_64/linux-tools/
https://www.archlinux.org/packages/extra/x86_64/calligra/

Unfortunatly, packages doesn't have pkgbase information stored, so
pacman is not able to find by $pkgbase.
But we can use provides and groups to have a search working.

By example, use group information, named by project name, which allow
users which want use PyQt to search
pacman -Ss pyqt and found python-qt and python2-qt.
And users who (gracefully) writes "pacman -S pyqt" will be asked to
choose which package to install.

>> We worked around this for a while using 'PyQt:' in the description so
>> that it'd come up in searches for 'pyqt'. You could also provide for
>> it in both, but that would still be a workaround.
>
> python2-pyqt
> python2-pygtk
>
> The little bit of redundancy (python-py) isn't too bad IMHO and it's a
> clear naming scheme without special cases.

It's a compromise but squeezing the redundancy would be plus.
Even change the package name, change it to something much more coherent.

All of this works until there is no 2 different packages nammed PyQt4
and PythonQT. It's unlikely?

Cheers,

--
Sébastien "Seblu" Luttringer
www.seblu.net
 
Old 09-14-2012, 08:54 AM
Rashif Ray Rahman
 
Default Python 3.3.0 and PEP 394

On 14 September 2012 05:26, Sébastien Luttringer <seblu@seblu.net> wrote:
> I'm not sure it's very important (and possible) to use the project
> name without alteration in our package name.
> As you said, the most important is to be able to find it (by a search)
> with a minimum common sense.
>
> Developer which use pyqt, will search something like:
> $ pacman -Sqs pyqt4
> eric
> eric4
> and doesn't found it. Because they may use the real name of the python
> library (import PyQt4).
> ...
> SNIP
> ...

Good one, we must provide for that. Nevertheless, what I meant was
_not_ to have:

python-qt
python2-qt
python-gtk
python2-gtk

But to have:

pyqt
python2-pyqt
pygtk
python2-pygtk

As we have now. Prepending 'python' everywhere is fine, as long as the
'pyX' name remains. Now the ideal scenario would be:

John: Fetch me 'pyalpm'
Pacman: Do you want python(3)-pyalpm or python2-pyalpm?

Now that I look at it that way prepending 'python' would be better.


--
GPG/PGP ID: C0711BF1
 
Old 09-14-2012, 09:16 AM
Lukas Jirkovsky
 
Default Python 3.3.0 and PEP 394

On 14 September 2012 10:54, Rashif Ray Rahman <schiv@archlinux.org> wrote:
>
> Good one, we must provide for that. Nevertheless, what I meant was
> _not_ to have:
>
> python-qt
> python2-qt
> python-gtk
> python2-gtk
>
> But to have:
>
> pyqt
> python2-pyqt
> pygtk
> python2-pygtk
>
> As we have now. Prepending 'python' everywhere is fine, as long as the
> 'pyX' name remains. Now the ideal scenario would be:
>
> John: Fetch me 'pyalpm'
> Pacman: Do you want python(3)-pyalpm or python2-pyalpm?
>
> Now that I look at it that way prepending 'python' would be better.
>
>
> --
> GPG/PGP ID: C0711BF1

Just my 2 cents: I'd prefer "python-something" when the "something" is
compatible with both Python 2 and Python 3, and reserve
python2-something/python3-something when the "something" works only
under version of Python specified in the name.

Lukas
 
Old 09-14-2012, 10:56 AM
Stéphane Gaudreault
 
Default Python 3.3.0 and PEP 394

Le 2012-09-14 05:16, Lukas Jirkovsky a écrit :

On 14 September 2012 10:54, Rashif Ray Rahman <schiv@archlinux.org> wrote:

Good one, we must provide for that. Nevertheless, what I meant was
_not_ to have:

python-qt
python2-qt
python-gtk
python2-gtk

But to have:

pyqt
python2-pyqt
pygtk
python2-pygtk

As we have now. Prepending 'python' everywhere is fine, as long as the
'pyX' name remains. Now the ideal scenario would be:

John: Fetch me 'pyalpm'
Pacman: Do you want python(3)-pyalpm or python2-pyalpm?

Now that I look at it that way prepending 'python' would be better.


--
GPG/PGP ID: C0711BF1

Just my 2 cents: I'd prefer "python-something" when the "something" is
compatible with both Python 2 and Python 3,
Is there any such package ? .py files could be compatible for both
version, but .pyc and .pyo files are not.

and reserve
python2-something/python3-something when the "something" works only
under version of Python specified in the name.

Lukas
 
Old 09-14-2012, 11:10 AM
Lukas Jirkovsky
 
Default Python 3.3.0 and PEP 394

On 14 September 2012 12:56, Stéphane Gaudreault <stephane@archlinux.org> wrote:
> Is there any such package ? .py files could be compatible for both version,
> but .pyc and .pyo files are not.

Good point! But not all packages contains .pyc and .pyo, eg.
python2-pyqt provides only .py files.
 
Old 09-14-2012, 01:00 PM
Rashif Ray Rahman
 
Default Python 3.3.0 and PEP 394

Xyne didn't appear to have write access so passing on his message as follows:

---------- Forwarded message ----------
From: Xyne <xyne@archlinux.ca>
Date: 14 September 2012 19:57
Subject: Re: [arch-dev-public] [RFC] Python 3.3.0 and PEP 394


Rashif Ray Rahman wrote:

>Good one, we must provide for that. Nevertheless, what I meant was
>_not_ to have:
>
>python-qt
>python2-qt
>python-gtk
>python2-gtk
>
>But to have:
>
>pyqt
>python2-pyqt
>pygtk
>python2-pygtk
>
>As we have now. Prepending 'python' everywhere is fine, as long as the
>'pyX' name remains. Now the ideal scenario would be:
>
>John: Fetch me 'pyalpm'
>Pacman: Do you want python(3)-pyalpm or python2-pyalpm?
>
>Now that I look at it that way prepending 'python' would be better.


I also think that prefixing "python" in all cases makes sense. The prefix
indicates that it is a library/module in our naming scheme and omitting it even
in the case of naming redundancy (e.g. python-py*) creates exceptions to an
otherwise uniform rule.

I also strongly support the idea of using

python3-foo
python2-foo

even if Python 4 may be a long way off. It is a consistent naming scheme that
is completely unambiguous and it will avoid considerable hassle when Python 4
is finally released.

I think simple rules should be preferred and in the case of python
libraries/modules the simplest one is this:

python<version>-<project name>

e.g. "python3-pyalpm"

Both the version and project name are clear, and it is fully searchable with
Pacman.

When a user is looking for a Python package, the user is not looking for a
given project but rather a specific implementation of that project that is
compatible with their own project. The user doesn't just want "foo", the user
wants an implementation of "foo" in e.g. Python 3. It does indeed make sense to
ask the user which version he wants (python2-foo or python3-foo?).

The last argument that I have for always including the version number in the
"python" prefix is that Python 2 and Python 3 are effectively different
languages. There should be a unique prefix associated with each language for
consistent naming, and that prefix should be permanent to avoid compatibility
issues in the future. "python3-" clearly indicates that the package is for the
Python 3 language. "python-" is a much more nebulous term that simply indicates
that the package is for some version of Python that depends on when the package
was created.

The KISS approach here comes at the cost of a single character ('3') in
some package names. Given all the hassle that it saves, I think it is clearly
worth a few hundred bytes.

Regards,
Xyne
---------- Forwarded message ----------


--
GPG/PGP ID: C0711BF1
 
Old 09-14-2012, 01:14 PM
Alexander Rødseth
 
Default Python 3.3.0 and PEP 394

Would it be feasible to install the needed files for both python2 and python3?
If John said "Fetch me 'pyalpm'", could he not get a few files
installed in both /usr/lib/python2.7/ and /usr/lib/python3.2/?
The disk usage is negligible and having both installed would be
unproblematic (or at least be likely to solve more problems than it
creates).

There are other examples of packages including more files than
strictly requested, like header files in lib* packages and additional
documentation and examples for some packages.

If this feels to un-Arch-like, a "clean cut" alternative would be to
drop python2 completely and move everything that has to do with
python2 to AUR, only keeping python3 and just prepend all python
package names with "python-".

Just my two cents, please don't flame me.

--
Best regards,
Alexander Rødseth, TU
 
Old 09-14-2012, 01:19 PM
Allan McRae
 
Default Python 3.3.0 and PEP 394

On 14/09/12 23:14, Alexander Rødseth wrote:
> If this feels to un-Arch-like, a "clean cut" alternative would be to
> drop python2 completely and move everything that has to do with
> python2 to AUR, only keeping python3 and just prepend all python
> package names with "python-".

python2 is not being dropped.
 
Old 09-14-2012, 01:25 PM
Stéphane Gaudreault
 
Default Python 3.3.0 and PEP 394

Le 2012-09-14 09:19, Allan McRae a écrit :

On 14/09/12 23:14, Alexander Rødseth wrote:

If this feels to un-Arch-like, a "clean cut" alternative would be to
drop python2 completely and move everything that has to do with
python2 to AUR, only keeping python3 and just prepend all python
package names with "python-".

python2 is not being dropped.



I think it is good a good practice to try to move as much as possible to
python 3, but python 2 will remain supported for some years. As a point
of reference, upstream will provide maintenance releases for python 2
until at least 2015.


Stéphane
 

Thread Tools




All times are GMT. The time now is 12:57 PM.

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