On Sun, Aug 27, 2017 at 2:13 AM, Cameron Simpson <c...@cskk.id.au> wrote:
> On 26Aug2017 21:27, boB Stepp <robertvst...@gmail.com> wrote:
>>
>> I have a project structure where I am developing various programs,
>> some in Pinnacle HotScript language, some in Perl, some in Python,
>> some shell scripts. For the purpose of this question, my simplified
>> development file structure is:
>>
>> ~/_dev_Scripts
>> /ScriptMenuSystem
>> __init__.py
>> test.py
>>
>> /py_utilities
>> __init__.py
>> test.py
>>
>> When I am fully happy (Not really! ~(:>)) ) with everything I will
>> copy everything pertinent from "~_dev_Scripts" into a location like
>> "/usr/local/.../Scripts/boB_Scripts". So all code must be able to
>> handle any change in location from where I am developing it. On to my
>> difficulties ...
>>
>> ScriptMenuSystem/test.py:
>>
>> -------------------------------------------------
>> #!/usr/bin/env python
>>
>> import sys
>> sys.path.append('..')
>>
>> import py_utilities.test as t
>>
>> t.test_print()
>
>
> The trouble with this specific approach is that '..' relies on your
> _working_ directory being above ScriptMenuSystem i.e. the directory you
> shell's in; '..' is not related to the path to the test.py file. What yu
> want for this is the actual path to the code i.e. __file__. Eg:
>
> sys.path.append(dirname(dirname(__file__)))
I tried to use this (on Python 2.4/2.6 -- one server has 2.4, the
other 2.6) and got the following:
Traceback (most recent call last):
File "... /test.py", line 9, in <module>
sys.path.append(dirname(dirname(__file__)))
NameError: name 'dirname' is not defined
Is this a version issue or do I have the syntax wrong?
Anyway, I tried something a bit different that implemented this:
pgm_dir = os.path.dirname(os.path.abspath(__file__))
pgm_root = pgm_dir.replace('/ScriptMenuSystem', '')
sys.path.append(pgm_root)
And this gave me the results I wanted. Funny that 'dirname' works
with os.path but not with sys.path.
BTW, I have not used os.walk yet, but would that be better than my bit
of string manipulation above? If yes, an example of walking up and
getting the directory exactly one level up from __file__ would be
appreciated.
> but that requires your module to know its own location within your library
> i.e. that it is .../dev_scripts/ScriptMenuSystem/test.py, and therefore
> that you want .../dev_scripts. Fragile. (And __file__ doesn't work in some
> more arcane ways of distributing modules, such as in zip files but let's not
> go there, not least because I've never done that myself).
I have been using the same project structure for some years now, so in
that sense it is well-established and not fragile. I don't anticipate
it changing. There is actually no installation in a traditional
sense. Once I develop something worth using, it gets copied (by me as
root) from my user area to an accessible location to those users that
requested access. I had been doing this copying to each user's area,
but that has grown unwieldy as my couple of users have grown into
around 15. So I am moving to put everything in a centrally accessible
location and will probably adopt Steve's suggestion to establish a
group with permissions to use these programs.
So I think this idea (Or some variation thereof.) is what I need to
do. Or the good experts here show me I'm engaged in foolishness!
Cheers!
--
boB
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
