[gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Sebastian Pipping
Hello,


to better communicate USE_PYTHON we could use:

 - a portage news entry

 - notifications from within ebuilds

 - a users guide counterpart of
   http://www.gentoo.org/proj/en/Python/developersguide.xml

 - mentioning in 'man make.conf'

This is overdue and has some urgency.


Are you volunteering to get this going?

Feel free to derive from http://blog.hartwork.org/?p=972.

As it involves a GLEP and GuideXML maybe that's perfect for involving
people being recruited at the moment.


Thanks for your consideration.

Best,



Sebastian



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Fabian Groffen
On 03-12-2010 11:35:14 +0100, Sebastian Pipping wrote:
 to better communicate USE_PYTHON we could use:
 
  - a portage news entry

why portage?

  - notifications from within ebuilds
 
  - a users guide counterpart of
http://www.gentoo.org/proj/en/Python/developersguide.xml
 
  - mentioning in 'man make.conf'

why? make.conf is for custom settings for Portage.  Python ebuilds
should solve this, preferably matching the slots of python being
installed.

 This is overdue and has some urgency.
 
 
 Are you volunteering to get this going?
 
 Feel free to derive from http://blog.hartwork.org/?p=972.
 
 As it involves a GLEP and GuideXML maybe that's perfect for involving
 people being recruited at the moment.

Why a GLEP?  The only thing you can do just now, is to make USE_PYTHON
default to something people would expect, and to be properly documented,
such that it turns up in search result somewhere at the top.  (Last time
I needed it, I couldn't find it any more.)


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Michał Górny
On Fri, 03 Dec 2010 11:35:14 +0100
Sebastian Pipping sp...@gentoo.org wrote:

 to better communicate USE_PYTHON we could use:

The first question that comes into my mind is -- why do we need
to communicate that? I think that USE_PYTHON is a pretty specific
variable which should be used only if specially required (i.e. to keep
multiple Python versions ready for use).

What needs to be fixed IMO is the default value of that variable.
If you already disabled switching the active Python version by default,
you should also make the Python eclass base its' USE_PYTHON defaults
on the active Python version.

  - notifications from within ebuilds

Unnecessary repeated complaints are always helpful to users. I think
that an elog after Python upgrade should be sufficient.

  - mentioning in 'man make.conf'

Not related. We don't describe VIDEO_CARDS, LIRC_DEVICES etc. in that
file too.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Sebastian Pipping
On 12/03/10 12:50, Fabian Groffen wrote:
 On 03-12-2010 11:35:14 +0100, Sebastian Pipping wrote:
 to better communicate USE_PYTHON we could use:

  - a portage news entry
 
 why portage?

I'm speaking of GLEP 42.  No idea if pkgcore or paludis support these.
That's why i said portage.

http://www.gentoo.org/proj/en/glep/glep-0042.html


  - notifications from within ebuilds

  - a users guide counterpart of
http://www.gentoo.org/proj/en/Python/developersguide.xml

  - mentioning in 'man make.conf'
 
 why? make.conf is for custom settings for Portage.

Good point.  Still, as of now that's where to put USE_PYTHON.
I'm unsure if that's a reason strong enough to add it.


 As it involves a GLEP and GuideXML maybe that's perfect for involving
 people being recruited at the moment.
 
 Why a GLEP?

It involves usage of a GLEP, not creating a new one.
Sorry, if I did not put this clearly.

Best,



Sebastian



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Sebastian Pipping
On 12/03/10 13:05, Michał Górny wrote:
 The first question that comes into my mind is -- why do we need
 to communicate that? I think that USE_PYTHON is a pretty specific
 variable which should be used only if specially required (i.e. to keep
 multiple Python versions ready for use).
 
 What needs to be fixed IMO is the default value of that variable.
 If you already disabled switching the active Python version by default,
 you should also make the Python eclass base its' USE_PYTHON defaults
 on the active Python version.

USE_PYTHON hits people when emerging a new 2.x slot.
Say they have 2.6 installed and add 2.7 to that.

I agree, that its default value may need re-consideration.
After that, patches to the python eclass are needed.

Depending on how fast we can fix that, communicating status quo before
that may still help reduce user frustration.  Especially as we have an
unmasked 2.7.1 in tree for a few days now.


  - mentioning in 'man make.conf'
 
 Not related. We don't describe VIDEO_CARDS, LIRC_DEVICES etc. in that
 file too.

Yes, but that's USE_EXPAND stuff - USE_PYTHON is different, at least at
the moment.  You may still be right, though.



Sebastian



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Sebastian Pipping
On 12/03/10 13:23, Sebastian Pipping wrote:
 Good point.  Still, as of now that's where to put USE_PYTHON.

^^^ referring to /etc/make.conf itself.


 I'm unsure if that's a reason strong enough to add it.

^^^ referring to the man page of 'make.conf'.



Sebastian



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Michał Górny
On Fri, 03 Dec 2010 13:29:14 +0100
Sebastian Pipping sp...@gentoo.org wrote:

 Depending on how fast we can fix that, communicating status quo before
 that may still help reduce user frustration.  Especially as we have an
 unmasked 2.7.1 in tree for a few days now.

Then the question would be -- if that version causes so much trouble
and requires a careful re-consideration of upgrade schema, why didn't
anyone mask it yet?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Sebastian Pipping
On 12/03/10 14:16, Michał Górny wrote:
 Then the question would be -- if that version causes so much trouble
 and requires a careful re-consideration of upgrade schema, why didn't
 anyone mask it yet?

I didn't dare to.




Sebastian



Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Richard Freeman
On 12/03/2010 07:05 AM, Michał Górny wrote:
 On Fri, 03 Dec 2010 11:35:14 +0100
 Sebastian Pipping sp...@gentoo.org wrote:
 
 to better communicate USE_PYTHON we could use:
 
 The first question that comes into my mind is -- why do we need
 to communicate that? I think that USE_PYTHON is a pretty specific
 variable which should be used only if specially required (i.e. to keep
 multiple Python versions ready for use).

I tend to agree.  For a user who doesn't actually USE python, but just
has it installed because half of the rest of the system doesn't work
without it, python is just another dependency.  If a package only works
with python v1.2, then it should depend on the appropriate slot/etc.

If a user actually USES python, then they should have a mechanism to
tell the system what versions of python to keep around.  If you could
put slots in the world file that might do the trick, but this variable
seems like a reasonable way to do it as well.

 
 What needs to be fixed IMO is the default value of that variable.
 If you already disabled switching the active Python version by default,
 you should also make the Python eclass base its' USE_PYTHON defaults
 on the active Python version.

I tend to agree here as well.  The distro should manage the version used
for distro packages.  Maybe a user wants to do cutting-edge development
work in python-v12.  The system should still use a sane version of
python to run portage/etc, unless the user specifically tells it to do
otherwise.

Rather than hard-coding this in every package a distro-wide default
probably makes sense.  When new versions of python are deemed acceptable
for distro-wide use the default can be updated.

Gentoo has to work reasonably well without having to micro-manage python
versions.  Users shouldn't have to figure out what version of python
they want to run to do an install.

Rich