Best practices regarding PYTHONPATH

[Thomas Jollans]

On 09/03/2021 22:52, Cameron Simpson wrote:
> On 09Mar2021 05:00, Larry Martell <larry.martell at gmail.com> wrote:
>> Which is considered better? Having a long import path or setting PYTHONPATH?
>>
>> For example, in a project where 50% of the imports come from the same top
>> level directory is it better to add that dir to the path or reference it in
>> the import statements?
> All the below is personal opinion.
>
> I'd be leaving the $PYTHONPATH alone - I tweak it to access the required
> libraries, but not to change their dotted module paths.
>
> For example, I include ~/lib/python in my personal environment to access
> my personal modules, but I don't include
> ~/lib/python/cs/app/someapp/subpackage in order to shorten
> "cs.app.someapp.subpackage.foo" to just "foo".
>
> This is largely to avoid accidental shadowing of other modules. For
> example, supposing "foo" above were the subpath "os.path". Yes,
> contrived, but that's the flavour of problem I'm avoiding.
>
> I think I'd be ok with it provided I didn't go too far down. Eg, if all
> my "someapp"s were distinctively named I could be persuaded to use
> ~/lib/python/cs/app in the $PYTHONPATH, allowing
> "someapp.subpackage.foo". But I'd still be reluctant.

If you have a bunch of different packages you want to think of as "top 
level" but that live in different places for organizational reasons 
(e.g. someapp in ~/lib/python/cs/app/someapp and thatlib in 
~/lib/python/cs/lib/util/thatlib), I'd advocate treating them as proper 
Python packages with their own setup.py and everything, and installing 
them properly.

Editable installs (setup.py develop or pip install -e .) are great for this.

Personally when this is impractical for some reason I prefer creating 
*.pth files in site-packages to messing with PYTHONPATH as I find this 
easier to maintain, especially if you ever end up using different Python 
versions or different virtual environments.

Just my 0.02 €.


>
> If the project modules are tightly bound relative imports can get you a
> fair way. Certainly within a package I do a lot of:
>
>      from .fixtures import these_things
>
> to grab from the adjacent "fixtures.py" file instead of:
>
>      from project.submodule.fixtures import these_things
>
> And I'm usually happy to go up an additional level:
>
>      from ..package2.fixtures import those_things
>
> Somewhere around 3 dots I start to worry about presuming too much, but
> that is an arbitrary decision based on the discipline (or lack of it) in
> the project naming.
>
> Cheers,
> Cameron Simpson <cs at cskk.id.au>