error messages unclear

[Paul G.]

> On Tuesday 03 December 2002 17:05, Paul G. wrote:
> > Hi folks,
> >
> > 	Keep getting this, and am still not exactly sure how to decode it.
> >
> > > AttributeError: 'module' object has no attribute 'path'
> 
> [snip snippity snip snip]
> 
> > 	Finally, the auto-traceback adds this:
> >
> > 		  File ".../python-2.2.1/Lib/distutils/sysconfig.py", line 23, in
> > ?
> >     PREFIX = os.path.normpath(sys.prefix)
> 
> For the sake of answering the direct question you posed (about how to
> 'decode' the error message), the 'os' module is a standard one
> (included in your distribution), and a standard component of that
> module is the 'path' submodule.  Somehow, the python you are running
> cannot find the 'path' submodule.  All the stuff about 'normpath' is a
> red herring; the os module itself somehow doesn't have 'path' and THAT
> is exactly what the error is telling you.  It needs 'path' before it
> can resolve 'normpath'
> 
> Now, having a broken 'os' module like this probably means your
> installation is kind of messed up.  So, let's move on for a bit...
> 
> > 	Here is the complete text of the error:
> >
> > 	$ make
> > gcc   -o python.exe \
> >                 Modules/python.o \
> >                 libpython2.2.a    -lm
> [snip]
> > Traceback (most recent call last):
> >   File "./setup.py", line 7, in ?
> >     from distutils import sysconfig
> >   File "\msys\1.0\src\python-2.2.1/Lib/distutils/sysconfig.py", line
> >   23, in
> > ? PREFIX = os.path.normpath(sys.prefix)
> > AttributeError: 'module' object has no attribute 'path'
> [snip]
> 
> > 	AttributeError: 'module' object has no attribute 'path'
> >
> > 	really is saying nothing that might help in terms of what the
> > actual cause of the error in fact "is".
> 
> Yes, it is all there.  I'll get to that.
> 
> > 	os.path.normpath(sys.prefix) is not verbalized, nor is it,
> > apparently, defined to be constant for any system.
> 
> Not sure what you mean, but I can tell you that 'os' is a module that
> should come installed with any Python distribution.  A submodule of
> 'os' is 'path' that has services like 'normpath'.  Yours is messed up,
> so that there is no 'path' and hence no 'normpath'.  

>For example, in a
> working install, you would be able to do something like this (I'm on
> unix, but it'll work similarly for windows):
> 
> $ python
> Python 2.2.2 (#1, Nov 21 2002, 08:18:14)
> >>> import sys
> >>> import os
> >>> os.path
> <module 'posixpath' from '/usr/lib/python2.2/posixpath.pyc'>

Ok.  So where is your 'posixpath' defined?  How is it defined?  Why is it defined the way that 
it is?  Is it defined based on uname, pyconfig.in.h, pyconfig.h or something else entirely?

> >>> os.path.normpath(sys.prefix)
> '/usr'
> 
> If I delete os.path, I will get the error you saw:

	Still is not clear as to what you define as os.path.

	os.path=?.  Why, where, how?

> 
> >>> del os.path
> >>> os.path.normpath(sys.prefix)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: 'module' object has no attribute 'path'
> 
> So, the only question is why is your Python installation messed up?
> 
> > 	I am not using Cygwin.
> 
> So, looking again at the compile line, it would appear that you are in
> fact trying to build Python under windows, using gcc that is not a
> cygwin gcc...  Am I correct?

	Specifically it is a gcc and it is a variation/fork on Cygwin.  However, it is not Cygwin.  It is 
not about the compiler I am using, nor is it about the way I am using that compiler.  That, to 
me, is a red herring.  As to OS, well, it varies, so that too is a red herring.  What it is about is 
the way that python.exe is actually built/prepared during and after "autoconfistication" is 
handled.

>  Do you already have an installed python
> distribution?

	No.

>  I am assuming you are on Windows, because your paths
> have mixed "\" and "/" characters in them, although it also appears
> you are trying to use a "unix-like" build environment (make/gcc/etc.) 

	That mixed separator stuff may be causing it.  I am asking if it is or it is not, amongst 
other things.

> Furthermore, you are building a python.exe, which implies you are
> building the Python executable.  But, you are also using a python.exe
> to do the build (ie, "./python.exe -E ./setup.py -q build;;").

	That is the way that the autoconfistication has set things up.  I have done nothing in 
terms of that portion of the autoconfistication.  That is what is being produced by the stuff I 
have downloaded from the python cvs repository.  Again, I still do not know if the mixed 
separator is causing the problems.

> 
> Now, not having built python on Windows at all, much less using a
> "unix-like" environment, I'm not sure what is going on.  But my guess
> is that somehow everything is just getting hosed, either because you
> are overwriting the environment with an incomplete one, or something
> else.

	Ok.  So, in fact, you don't know what is going on with it either.  That would indicate to me 
that the AttributeError: is really quite meaningless aside from the assumption you made in 
terms of a particular 'path' value.

	Perhaps this wil help:  when I launch python, and input the values you suggested, python 
chokes when it gets to 'path'.  I already knew that would happen.  What I do not know is 
where, and/or how, 'path' is defined in the first place.  Does anyone know?

	(term "module', below, is not clear to me within the context of python.  There are 
modules and there are 'modules'.  Which module are we talking about here?  A python 
module or something else entirely?

	Fwiw, the error, under python is this:  No module named 'path'

	Back to square one:  Where is 'path' module defined?  How is it defined?


>  But without knowing more
> about what you are trying to build, and what tools you are using, I
> can only give speculative fixes.

	I am not trying to 'build' anything.  I am trying to understand how python works.

>  If you just want to run Python, you
> should download some Python executables for Windows (there are various
> types, with installers, etc.)  If you want to build python yourself,
> and already have a working python, you need to be careful about your
> paths when building, I suspect.

	I have built python.  The working version of python that I have is one I have already built 
from cvs source.

	Python test is failing.  Because python test is failing, I am attempting to figure out why so 
I can tweak the appropriate bits and pieces.

>  Others have done the same, so post
> more details and people can probably help.

> If you ARE using Cygwin
> (which I suspect you are, and the above was a typo), then I'm pretty
> sure Cygwin already has a pre-built Python.  Did you want to compile
> that with different options.

	To both unvoiced questions, the answer is "Nope".  I am not using Cygwin.  Banish the 
thought that I might be, as it will only confuse the issues.  I am in the process of putting 
together/providing a pre-built python for something else entirely.

> 
> Finally, if you are not building python at all, then the error text
> you posted seems very confusing indeed.

Ok.

	It occurs at the end of the "make" process.  After eliminating the possibility that "make" is 
the cause (invalid syntax, etc.), I am left with the autoconfistication process and the source 
code itself.  After eliminating autoconfistication process as the culprit, I am left with the 
source code itself.  Thus the questions about "why", "where" and "how".

	Currently and dealing with "make" and the following error:

gcc   -o python.exe \
                Modules/ccpython.o \
                libpython2.2.a    -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='ld' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' 
./python.exe -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='ld' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' 
./python.exe -E ./setup.py build;; \
esac
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 7, in ?
    from distutils import sysconfig
  File "\msys\1.0\src\python-2.2.1/Lib/distutils/sysconfig.py", line 23, in ?
    PREFIX = os.path.normpath(sys.prefix)
AttributeError: 'module' object has no attribute 'path'
make: *** [sharedmods] Error 1

	Python is already built at this point in the make process, that is why 'python' is being 
invoked.

	Actually, python is being invoked in order to test (according to make file, etc.) 'python'.  
The test fails.  The target, as you see above, is sharedmods.

	Python is generating the error.

	If Python is generating the error, then that leaves me with the source code.

	At the source code level, I am trying to establish which source code file (or collection of 
source code files) is not doing what I expect it to do.  What I expect Python to do is to pass 
the test.  It has yet to do so, even though Python.exe has been generated.

> 
> In any case, I know this is a verbose message, and that you are
> probably frustrated after some time looking through code and trying to
> build your program (or python environment).  But, with some more
> specific information about what you are trying to accomplish (ie.
> build python on Windows using gcc and make), I'm sure people will be
> able to help.

	All I am really trying to accomplish is to get the Python test processes to work properly.  
That's it.

	Unfortunately, it is not an easy task to concisely and simply state such things.  Most 
folks, that have helped (and I have appreciated it everyone) need to have more information 
in terms of what is going on.  So much for concise...

	Anyway, hope that what I have added here is helpful.

	Paul G.