.pth file has no effect in editable install

[chrisjbillington]

.pth files only work if they're in a site packages directory. Editable installs add the current directory to the path, but they don't add them as site directories so no .pth files get processed.

Perhaps labscript_utils should process the .pth file at import time, if it sees that it has not already been processed. Then user code will be available in the interpreter so long as a labscript suite module has been imported.

[chrisjbillington]

Extra comments from a duplicate issue I filed after forgetting I already filed this one:

---

This .pth file adds userlib and pythonlib (as defined in labconfig) to the python import path to make user code available for import from the python interpreter regardless of whether the code is running within a labscript suite program.

We could:

• Work out how to get it into a site directory during an editable install (possibly not reversible or otherwise a bit magic)
• Convince Python that .egg-link files should imply the target directory is a site directory to be processed by the site module, make a patch and wait for them to incorporate it
  Work out if there's some way to otherwise add our package directory as a site directory during editable install.
• Live with it and instead process the .pth file whenever labscript_utils is imported. This means user code would not be available for import in editable installs when not running inside a labscript suite program, unless labscript_utils has been imported. This could simply be documented as a limitation of editable installs.

[rpanderson]

Live with it and instead process the .pth file whenever labscript_utils is imported.

I'm fine with this less magical option that will be easily documented and implemented by those with an editable install.

[philipstarkey]

• Work out how to get it into a site directory during an editable install (possibly not reversible or otherwise a bit magic)

Can we not just modify labscript-profile-create to locate the site-packages directory using site.getsitepackages() and then copy the .pth file there if it doesn't already exist?

[chrisjbillington]

Can we not just modify labscript-profile-create to locate the site-packages directory using site.getsitepackages() and then copy the .pth file there if it doesn't already exist?

Absolutely. Just that this isn't reversible - if the user subsequently uninstalls the labscript suite modules, the .pth file will cause import errors to be printed every time they start a Python interpreter. Perhaps if I wrap its code in try:except: it will be harmless to leave the .pth file behind. But the code you can write in a .pth file is very limited, so even a try:except: might not be possible! I'll see. If so that is a decent solution IMHO.

edit:

using site.getsitepackages()

It's not that simple unfortunately, since you can't know whether the user site package or regular site packages is the right place. But I know what hoops to jump through to figure out which site directory is associated with an editable install. That logic is in some desktop-app functions where it has to figure out where the appropriate scripts directory is for an editable install (otherwise pretty tricky to work out!)

[philipstarkey]

Can we not just modify labscript-profile-create to locate the site-packages directory using site.getsitepackages() and then copy the .pth file there if it doesn't already exist?

Absolutely. Just that this isn't reversible - if the user subsequently uninstalls the labscript suite modules, the .pth file will cause import errors to be printed every time they start a Python interpreter. Perhaps if I wrap its code in try:except: it will be harmless to leave the .pth file behind. But the code you can write in a .pth file is very limited, so even a try:except: might not be possible! I'll see. If so that is a decent solution IMHO.

It's possible, but messy. You need to make the .pth file something like:

import sys; exec("try: import labscript_profile; labscript_profile.add_userlib_and_pythonlib()\nexcept ModuleNotFoundError: pass")
import sys; exec("try: import labscript_profile; labscript_profile.add_development_directories()\nexcept ModuleNotFoundError: pass")

This is because only lines starting with import are only ones that are executed (see here) so it has to start with an import that will succeed, but this can be followed by another arbitrary exec. Very much a hack, but then I'd argue the existing .pth file was just as much a hack to execute a specific function in labscript_utils.

edit:

using site.getsitepackages()

It's not that simple unfortunately, since you can't know whether the user site package or regular site packages is the right place. But I know what hoops to jump through to figure out which site directory is associated with an editable install. That logic is in some desktop-app functions where it has to figure out where the appropriate scripts directory is for an editable install (otherwise pretty tricky to work out!)

Sure!

[philipstarkey]

So the directory to put the .pth file in should be able to be found using desktop_app.environment._get_install_directory('labscript_utils')?

[chrisjbillington]

Correct!