Re: keygen problem generating cryptkey

Please keep the discussion on the list were other people can
contribute and benefit.

On Wed, Feb 9, 2011 at 9:54 PM, J. Maxwell <[email protected]> wrote:
> On 2/9/2011 11:18 AM, Kevin Goodsell wrote:
>
>> /usr/local/bin isn't what you need in the path. You need
>> /usr/local/lib/python2.6/site-packages, which is supposed to be added to
>> the path by the site module on interpreter startup. More on this below.
>>
>> Getting back to the problem at hand, it looks to me like Python was
>> configured incorrectly, or TMDA installed in the wrong location
>
> Could be an error in the ports collection, both were installed from the
> ports collection there

No, I was mis-interpreting the problem. My guess, that sys.prefix was
/usr instead of /usr/local, was incorrect. The reason
python2.6/site-packages was missing was that (as you pointed out in
another private email) you were running a different Python version, so
obviously python2.6 paths were not included.

>
> #1758:>=A0 python -c "import sys; print sys.prefix, sys.exec_prefix"
> /usr/local /usr/local
>
>> If neither one is /usr/local, that explains why
>> /usr/local/lib/python2.6/site-packages is missing from sys.path.
>
> Both are /usr/local
>
>> I suggest just creating a symlink to
>> /usr/local/lib/python2.6/site-packages/TMDA in the directory where
>> Python looks for site packages (probably sys.prefix +
>> '/lib/python2.6/site-packages')
>
> Then wouldn't it be looking in /usr/local/lib/python2.6/site-packages
>
> Created the link but got the same results
>
> #1759:> cd /usr/local
> /usr/local
> #1760:> ls -l TMDA
> lrwxr-xr-x=A0 1 root=A0 wheel=A0 43 Feb=A0 9 13:00 TMDA@ ->
> /usr/local/lib/python2.6/site-packages/TMDA

This is not what I meant at all. Python won't look in /usr/local for
modules. sys.prefix is just the *prefix* that it uses to construct
module paths. This is explained in the documentation for the site module:

http://docs.python.org/library/site.html

My suggestion was meaningless since sys.prefix is actually /usr/local.
The link location and target would be the same.

> #1761:>
> #1761:> tmda-keygen
> Traceback (most recent call last):
> =A0 File "/usr/local/bin/tmda-keygen", line 37, in <module>
> =A0=A0=A0 from TMDA import Version
> ImportError: No module named TMDA
> #1762:>
>
> Thinking that the TMDA@ link might be problematic, I created the directory
> ./TMDA and its sub-directories in /usr/local/ , then linked all the files
> across the directories.
> (wouldn't this be just reading the TMDA from /usr/local rather than
> /usr/local/lib/python2.6/site-packages ?)

You are just cluttering /usr/local. There was no reason to put anything
there.

>
> Got the same results, no matter where I ran tmda-keygen from
>
> Thank for all your assistance, greatly appreciated
>

Let me try to summarize what happened here.

1. The TMDA package directory was installed in
   /usr/local/lib/python2.6/site-packages/TMDA, but was not being found
   there, presumably because /usr/local/lib/python2.6/site-packages was
   not in sys.path.

2. I assumed (incorrectly) that Python was configured with a different
   site-packages prefix (probably /usr), which would cause the
   site-packages path to be, e.g., /usr/lib/python2.6/site-packages. I
   suggested adding a symlink at this location.

3. In fact, the site-packages location was
   /usr/local/lib/python2.7/site-packages because the Python version was
   2.7.

-Kevin

---------------------------------------------------------------------------=
---
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
tmda-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmda-users