-portage on native gentoo
 

Hi,

during bootstrap on native gentoo-linux I encountered this error:

Traceback (most recent call last):
File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
main()
File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
except portage.exception.PermissionDenied, e:
AttributeError: 'module' object has no attribute 'exception'

This is because portageq tries to 'import portage', and only if it
fails, it prepends sys.path with "/eprefix/usr/lib/portage/pym".

Prepending sys.path unconditionally helps here, because it accidentally
imported another portage:

--- usr/lib/portage/bin/portageq.orig 2007-12-07 16:14:26.768371000 +0100
+++ usr/lib/portage/bin/portageq 2007-12-07 16:14:48.689741000 +0100
@@ -434,14 +434,11 @@
sys.stderr.flush()
sys.exit(os.EX_USAGE)
os.environ["ROOT"] = sys.argv[2]
+ from os import path as osp
+ sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
+ global portage
+ import portage
try:
- global portage
- try:
- import portage
- except ImportError:
- from os import path as osp
- sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
- import portage
if uses_root:
sys.argv[2] = portage.root
retval = function(sys.argv[2:])

IMO having portage-provided "executables" (like emerge (does it?),
portageq, ...) relying on PYTHONPATH to "import portage" correctly is a
pain - not only in prefix: think of calling /usr/bin/portageq (the
"native" one) while prefix' PYTHONPATH is set up in environment...

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

Hi,

during bootstrap on native gentoo-linux I encountered this error:

Traceback (most recent call last):
File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
main()
File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
except portage.exception.PermissionDenied, e:
AttributeError: 'module' object has no attribute 'exception'

This is because portageq tries to 'import portage', and only if it
fails, it prepends sys.path with "/eprefix/usr/lib/portage/pym".

Prepending sys.path unconditionally helps here, because it accidentally
imported another portage:

--- usr/lib/portage/bin/portageq.orig 2007-12-07 16:14:26.768371000 +0100
+++ usr/lib/portage/bin/portageq 2007-12-07 16:14:48.689741000 +0100
@@ -434,14 +434,11 @@
sys.stderr.flush()
sys.exit(os.EX_USAGE)
os.environ["ROOT"] = sys.argv[2]
+ from os import path as osp
+ sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
+ global portage
+ import portage
try:
- global portage
- try:
- import portage
- except ImportError:
- from os import path as osp
- sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
- import portage
if uses_root:
sys.argv[2] = portage.root
retval = function(sys.argv[2:])

IMO having portage-provided "executables" (like emerge (does it?),
portageq, ...) relying on PYTHONPATH to "import portage" correctly is a
pain - not only in prefix: think of calling /usr/bin/portageq (the
"native" one) while prefix' PYTHONPATH is set up in environment...

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

--
Michael Haubenwallner
Gentoo on a different level

--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On 07-12-2007 16:34:14 +0100, Michael Haubenwallner wrote:
> Hi,
>
> during bootstrap on native gentoo-linux I encountered this error:
>
> Traceback (most recent call last):
> File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
> main()
> File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
> except portage.exception.PermissionDenied, e:
> AttributeError: 'module' object has no attribute 'exception'
>
> This is because portageq tries to 'import portage', and only if it
> fails, it prepends sys.path with "/eprefix/usr/lib/portage/pym".
>
> Prepending sys.path unconditionally helps here, because it accidentally
> imported another portage:
>
> --- usr/lib/portage/bin/portageq.orig 2007-12-07 16:14:26.768371000 +0100
> +++ usr/lib/portage/bin/portageq 2007-12-07 16:14:48.689741000 +0100
> @@ -434,14 +434,11 @@
> sys.stderr.flush()
> sys.exit(os.EX_USAGE)
> os.environ["ROOT"] = sys.argv[2]
> + from os import path as osp
> + sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> + global portage
> + import portage
> try:
> - global portage
> - try:
> - import portage
> - except ImportError:
> - from os import path as osp
> - sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> - import portage
> if uses_root:
> sys.argv[2] = portage.root
> retval = function(sys.argv[2:])
>
> IMO having portage-provided "executables" (like emerge (does it?),
> portageq, ...) relying on PYTHONPATH to "import portage" correctly is a
> pain - not only in prefix: think of calling /usr/bin/portageq (the
> "native" one) while prefix' PYTHONPATH is set up in environment...

Hmmm... this needs some thinking. I believe the portage code was/is
already set up in such a way that it could do without a patched python
to have portage's paths in PYTHONPATH.

However, portage /does/ record which python it wants to use, so
eventually it gets the "correct" python libraries when NOT using
PYTHONPATH.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On Fri, 2007-12-07 at 18:11 +0100, Fabian Groffen wrote:

> > Traceback (most recent call last):
> > File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
> > main()
> > File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
> > except portage.exception.PermissionDenied, e:
> > AttributeError: 'module' object has no attribute 'exception'

> > IMO having portage-provided "executables" (like emerge (does it?),
> > portageq, ...) relying on PYTHONPATH to "import portage" correctly
> is a
> > pain - not only in prefix: think of calling /usr/bin/portageq (the
> > "native" one) while prefix' PYTHONPATH is set up in environment...
>
> Hmmm... this needs some thinking. I believe the portage code was/is
> already set up in such a way that it could do without a patched python
> to have portage's paths in PYTHONPATH.

Yes, but first it tries to find *portage* module(s) using default python
mechanism, which is PYTHONPATH first, then python builtin path.

>
> However, portage /does/ record which python it wants to use, so
> eventually it gets the "correct" python libraries when NOT using
> PYTHONPATH.

Problem here is not that it finds wrong python modules, but wrong
*portage* modules, because PYTHONPATH=/usr/lib/portage/pym

It (seems to) work when I unset PYTHONPATH before doing prefix.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On 10-12-2007 17:27:03 +0100, Michael Haubenwallner wrote:
> > However, portage /does/ record which python it wants to use, so
> > eventually it gets the "correct" python libraries when NOT using
> > PYTHONPATH.
>
> Problem here is not that it finds wrong python modules, but wrong
> *portage* modules, because PYTHONPATH=/usr/lib/portage/pym
>
> It (seems to) work when I unset PYTHONPATH before doing prefix.

Reason for this IMHO is for Portage developers to be able to tell
portage where it /should/ look for its stuff by simply setting
PYTHONPATH. If we ignore this var, Portage no longer would "listen" to
you.

However, I don't ever use it, so I don't care. I could apply a patch
such that it will always use the modules it was configured to do, but
I'm almost certain "upstream" won't merge that.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On Mon, 2007-12-10 at 18:20 +0100, Fabian Groffen wrote:
> On 10-12-2007 17:27:03 +0100, Michael Haubenwallner wrote:
> > > However, portage /does/ record which python it wants to use, so
> > > eventually it gets the "correct" python libraries when NOT using
> > > PYTHONPATH.
> >
> > Problem here is not that it finds wrong python modules, but wrong
> > *portage* modules, because PYTHONPATH=/usr/lib/portage/pym
> >
> > It (seems to) work when I unset PYTHONPATH before doing prefix.
>
> Reason for this IMHO is for Portage developers to be able to tell
> portage where it /should/ look for its stuff by simply setting
> PYTHONPATH. If we ignore this var, Portage no longer would "listen" to
> you.

In case this really is the (only) reason I'd find some configure-flag
"--enable-devmode" in combination with some USE-flag "devmode" useful...

>
> However, I don't ever use it, so I don't care. I could apply a patch
> such that it will always use the modules it was configured to do, but
> I'm almost certain "upstream" won't merge that.

Eventually we should add some 'unset PYTHONPATH' to both the bootstrap
procedure as well as etc/profile ...

Or just don't set PYTHONPATH in main gentoo, if portage knows where to
find itself...

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On 10-12-2007 19:04:05 +0100, Michael Haubenwallner wrote:
> On Mon, 2007-12-10 at 18:20 +0100, Fabian Groffen wrote:
> > On 10-12-2007 17:27:03 +0100, Michael Haubenwallner wrote:
> > > > However, portage /does/ record which python it wants to use, so
> > > > eventually it gets the "correct" python libraries when NOT using
> > > > PYTHONPATH.
> > >
> > > Problem here is not that it finds wrong python modules, but wrong
> > > *portage* modules, because PYTHONPATH=/usr/lib/portage/pym
> > >
> > > It (seems to) work when I unset PYTHONPATH before doing prefix.
> >
> > Reason for this IMHO is for Portage developers to be able to tell
> > portage where it /should/ look for its stuff by simply setting
> > PYTHONPATH. If we ignore this var, Portage no longer would "listen" to
> > you.
>
> In case this really is the (only) reason I'd find some configure-flag
> "--enable-devmode" in combination with some USE-flag "devmode" useful...

Alternatively, we just make it listen to PORTAGE_PYTHONPATH or something
instead. I guess that would be acceptable for merging.

> > However, I don't ever use it, so I don't care. I could apply a patch
> > such that it will always use the modules it was configured to do, but
> > I'm almost certain "upstream" won't merge that.
>
> Eventually we should add some 'unset PYTHONPATH' to both the bootstrap
> procedure as well as etc/profile ...

I think this is a very good thing in the bootstrap procedure... even
though I basically already assume there that you have a clean shell.
Mentioning somewhere at the top won't hurt in any case. Do you know
where you can find those .xml documents?

> Or just don't set PYTHONPATH in main gentoo, if portage knows where to
> find itself...

I guess this option is due to multiple reasons not an option.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

The same problem occurs when you try to bootstrap on a system with
another bootstrapped image installed, and you think you can take a
shortcut by not bootstrapping python but using it from your existing
prefix...

On 07-12-2007 16:34:14 +0100, Michael Haubenwallner wrote:
> Hi,
>
> during bootstrap on native gentoo-linux I encountered this error:
>
> Traceback (most recent call last):
> File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
> main()
> File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
> except portage.exception.PermissionDenied, e:
> AttributeError: 'module' object has no attribute 'exception'
>
> This is because portageq tries to 'import portage', and only if it
> fails, it prepends sys.path with "/eprefix/usr/lib/portage/pym".
>
> Prepending sys.path unconditionally helps here, because it accidentally
> imported another portage:
>
> --- usr/lib/portage/bin/portageq.orig 2007-12-07 16:14:26.768371000 +0100
> +++ usr/lib/portage/bin/portageq 2007-12-07 16:14:48.689741000 +0100
> @@ -434,14 +434,11 @@
> sys.stderr.flush()
> sys.exit(os.EX_USAGE)
> os.environ["ROOT"] = sys.argv[2]
> + from os import path as osp
> + sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> + global portage
> + import portage
> try:
> - global portage
> - try:
> - import portage
> - except ImportError:
> - from os import path as osp
> - sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> - import portage
> if uses_root:
> sys.argv[2] = portage.root
> retval = function(sys.argv[2:])
>
> IMO having portage-provided "executables" (like emerge (does it?),
> portageq, ...) relying on PYTHONPATH to "import portage" correctly is a
> pain - not only in prefix: think of calling /usr/bin/portageq (the
> "native" one) while prefix' PYTHONPATH is set up in environment...
>
> /haubi/
> --
> Michael Haubenwallner
> Gentoo on a different level
>
> --
> gentoo-alt@gentoo.org mailing list
>

--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list

-portage on native gentoo
 

On 22-12-2007 21:24:40 +0100, Fabian Groffen wrote:
> The same problem occurs when you try to bootstrap on a system with
> another bootstrapped image installed, and you think you can take a
> shortcut by not bootstrapping python but using it from your existing
> prefix...

portage-2.2.00.9049 should fix this issue.


> On 07-12-2007 16:34:14 +0100, Michael Haubenwallner wrote:
> > Hi,
> >
> > during bootstrap on native gentoo-linux I encountered this error:
> >
> > Traceback (most recent call last):
> > File "/eprefix/usr/lib/portage/bin/portageq", line 467, in ?
> > main()
> > File "/eprefix/usr/lib/portage/bin/portageq", line 450, in main
> > except portage.exception.PermissionDenied, e:
> > AttributeError: 'module' object has no attribute 'exception'
> >
> > This is because portageq tries to 'import portage', and only if it
> > fails, it prepends sys.path with "/eprefix/usr/lib/portage/pym".
> >
> > Prepending sys.path unconditionally helps here, because it accidentally
> > imported another portage:
> >
> > --- usr/lib/portage/bin/portageq.orig 2007-12-07 16:14:26.768371000 +0100
> > +++ usr/lib/portage/bin/portageq 2007-12-07 16:14:48.689741000 +0100
> > @@ -434,14 +434,11 @@
> > sys.stderr.flush()
> > sys.exit(os.EX_USAGE)
> > os.environ["ROOT"] = sys.argv[2]
> > + from os import path as osp
> > + sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> > + global portage
> > + import portage
> > try:
> > - global portage
> > - try:
> > - import portage
> > - except ImportError:
> > - from os import path as osp
> > - sys.path.insert(0, osp.join(osp.dirname(osp.dirname(osp.realpath(__fi le__))), "pym"))
> > - import portage
> > if uses_root:
> > sys.argv[2] = portage.root
> > retval = function(sys.argv[2:])
> >
> > IMO having portage-provided "executables" (like emerge (does it?),
> > portageq, ...) relying on PYTHONPATH to "import portage" correctly is a
> > pain - not only in prefix: think of calling /usr/bin/portageq (the
> > "native" one) while prefix' PYTHONPATH is set up in environment...


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@gentoo.org mailing list