Opened 6 years ago

Closed 4 years ago

#1851 closed defect (wontfix)

finding python modules should not append

Reported by: jreed Owned by: UnAssigned
Priority: medium Milestone: Remaining BIND10 tickets
Component: Unclassified Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 4 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by jreed)

for example my installed bind10 has:

import sys; sys.path.append ('/var/users/jreed/dnsbench/work/master/201203272003
37/install/lib/python3.1/site-packages')
...
from bind10_config import LIBEXECPATH

But the LIBEXECPATH is defined from the /usr/local/lib/ version of bind10_config.py and not my version in my path above.

This causes all types of confusion when communicating with wrong msgq and cfgmgr so gets wrong configurations.

Subtickets

Change History (11)

comment:1 Changed 6 years ago by jinmei

The description isn't very clear to me...should LIBEXEC be LIBEXECPATH? Some specific
clarification will help.

comment:2 Changed 6 years ago by jreed

The old wrong versions of python modules are used because they are found first.

comment:3 Changed 6 years ago by jreed

  • Description modified (diff)

comment:4 Changed 6 years ago by jelte

  • Milestone changed from New Tasks to Sprint-20120417

comment:5 follow-up: Changed 6 years ago by jinmei

So, you've installed two sets of BIND10 python modules:

  • on under /var/users/jreed/dnsbench/.../site-packages
  • the other under /usr/local/lib/python3.x/site-packages or something,

and the latter happens to be in the system's default PYTHONPATH, and
then start the bind10 script that assumes that the modules are under
/var/users/jreed/...?

In that case, I suspect it's not (only) about appending the customized
path to the default paths. Other scripts executed by the boss process
and other stand-alone BIND 10 python scripts such as loadzone will
have the same problem, and if we want to make sure all of these use
the expected paths, we need to set PYTHONPATH environment correctly.

But I'm not sure if we want to do it within BIND 10 itself.
Installing different sets of BIND 10 to different places seems to be
quite unusual operation, and I suspect we might just ask such users to
set the PYTHONPATH environment variable explicitly in their
operational environment (in the shell, or a separate start script
etc), rather than complicating the main code further.

comment:6 Changed 6 years ago by jinmei

  • Owner set to jreed
  • Status changed from new to assigned

comment:7 in reply to: ↑ 5 Changed 6 years ago by jreed

  • Owner changed from jreed to UnAssigned

Replying to jinmei:

So, you've installed two sets of BIND10 python modules:

  • on under /var/users/jreed/dnsbench/.../site-packages
  • the other under /usr/local/lib/python3.x/site-packages or something,

and the latter happens to be in the system's default PYTHONPATH, and
then start the bind10 script that assumes that the modules are under
/var/users/jreed/...?

Yes, I have multiple BIND 10 python modules installed. Yes, I am trying to run my version under my home, but it uses the components from /usr/local/.

I think we should discuss this on a bi-weekly conference call.

comment:8 Changed 6 years ago by jelte

  • Milestone Sprint-20120529 deleted

comment:9 Changed 6 years ago by jreed

This is similar to #2735.

comment:10 Changed 4 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:11 Changed 4 years ago by tomek

  • Resolution set to wontfix
  • Status changed from assigned to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.