I think this should be quite easy to do, we can target de 2.0 milestone for this, for linux at least. Probably also for macOS. Not sure about Windows and permissions though.
What I have in mind:
"""helpers.py"""...definstall_otb(path:Path=Path.home()/"Applications",version:str="latest"):# Get binaries with requests thenos.system(f"sh {script_path} --target {path}")# or subprocessreturnpath/"OTB_DIR_NAME"
Then we could do, during module init:
try:importotbApplicationexceptModuleNotFoundError:ifos.environ.get("OTB_AUTO_INSTALL"):# or OTB_AUTO_INSTALL_DIRotb_dir=install_otb()os.environ["OTB_ROOT"]=otb_dirimportotbApplication
Edited
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
we should display information ("otb not found, trying to download + install binaries, ... etc")
what do you think its best: to enable auto install by default or not?
do you think it makes more sense to put the auto-install in the setup.py or at pyotb lauch?
since pyotb lifecycle follows closely otb, the OTB version to download could just be something static that we update for each pyotb release. I mean, no need for some kind of auto install that checks for OTB updates, do you agree?
Looks exiting to put that in 2.0 release but it has to be bullet proof!
By Rémi Cresson on 2023-08-09T13:53:21 (imported from GitLab)
not sure about that one, if not auto, users would have to manually call the function so it's still an enhancement but not as useful as the auto install
I don't know, I'd say at pyotb launch : we do not have a setup.py, it is supposed to go away especially to avoid this case of unsafe code being executed by pip install. But we could indeed re-introduce a setup.py for that purpose.
pyotb release cycle is kind of shorter than OTB's. I think we should not care about OTB releases, just offer to install the latest (since we always test against develop) or a specific version if provided.
So the auto / noauto question is tricky, it depends if we opt or not for the setup.py solution.
Then the question is should we auto install only if enabled via env variable.
# auto by default with optional[OTB_TARGET_DIR=][OTB_VERSION=] pip install pyotb# and for normal installOTB_AUTO_INSTALL=false pip install pyotb# vs# noauto by defaultpip install pyotb# to enableOTB_AUTO_INSTALL=true[OTB_TARGET_DIR=][OTB_VERSION=] pip install pyotb
I'd say it would be more elegant to auto install OTB during pip install (if import otbApplication failed), while still providing a way to disable it.
And the other hand, setup.py is deprecated and I'm not sure I want to re-introduce it.
Also this could result on most people not paying attention and having multiple OTB versions installed by mistake...
In that case we should at least implement OTB uninstallation for pyotb-installed dirs, during pip upgrades, to enable keeping OTB fresh without installing it 10 times.
In any case, I think we should provide a way to modify target OTB dir and version using env variables.
By Vincent Delbar on 2023-08-09T14:09:26 (imported from GitLab)
@remicress after more thinking, and considering the reasons above, I confirm I am not in favor of the setup.py option, it would be a nightmare to make it work on any platform, and more importantly it is deprecated.
I think the helpers.install_otb() function is enough, should be so simple that we can target 2.0.
When otbApplication is not found, we have two possibilities :
py process is interactive : OTB wasn't found, do you want to install it (yes/no) ? ; Provide a version number (latest by default): ; Installation directory ($HOME/Applications by default):.
py process is not interactive : print something like "OTB wasn't found, you can install it using python -c 'import pyotb ; pyotb.install_otb(version_spec, target_path)
We may discuss the default installation PATH, $HOME/Applications is default on macOS and the one I personally use on linux, it should work on windows also.
If it's in HOME, pyotb would be able to find it automatically, still it would be better to edit env variables, easy to modify .profile / .bashrc on linux, but for other systems I have no ideas.
Else, we could define a pyotb_dir standard which we always check when looking for otb, as done for /opt/otb and /opt/otbtf in helpers.find_otb().
I think it's better that way, we avoid scanning the HOME dir and make sure auto installed OTB are always found.
Then, if the user decides to use another path, he would be responsible to set the OTB_ROOT env variable by himself.
By Vincent Delbar on 2023-08-09T16:19:30 (imported from GitLab)
Oh yes I forgot about this. We need at least file and python3-dev to make it work, but we'll need cmake and swig to recompile bindings...
We could just print / inform user of what has to be installed.
And yes the wheel containing OTB binaries and dep libs would be cleaner but it's not the place for pyotb to do it...It would imply to build OTB from source, and build and distribute bindings for each possible python version. No idea how it works for windows.
By Vincent Delbar on 2023-08-09T22:02:28 (imported from GitLab)
Not what I meant ! I created the issue because I want us to do something now and not wait for OTB 12 to have proper distribution.
This install_otb() function can already help a lot and is easy to implement, it's the logical since to add in the existing find_otb helper.
By Vincent Delbar on 2023-08-10T09:38:26 (imported from GitLab)