otb: init at 9.0.0 #325630
otb: init at 9.0.0 #325630
Conversation
github-actions
bot
added
the
8.has: maintainer-list (update)
NixOSInfra
added
the
12. first-time contribution
ofborg
bot
added
8.has: package (new)
pkgs/by-name/ot/otb/package.nix
Outdated
| ]; | ||
|
|
||
|
|
||
| propagatedBuildInputs = [ |
There was a problem hiding this comment.
Why do we want to propagate all of this?
There was a problem hiding this comment.
Thanks @SuperSandro2000.
As OTB allows to build (remote) modules (officially not part of) on top of it, so we propagate the inputs to able to build remote modules based on OTB via nix as well. As I wasn't sure if all are needed so I tried to follow similar to ITK c.f
Example of remote modules for OTB:
There was a problem hiding this comment.
Not sure how this will integrate with nix. First of all propagatedBuildInputs are merged into buildInputs, so we don't need anything in buildInputs that is already in propagatedBuildInputs.
The other things, we don't want to propagate things if possible. Are those modules build with nix? If so we should move things to passthru. If not, then we just keep this ugly workaround for now until we have something better.
There was a problem hiding this comment.
Thanks @SuperSandro2000 !
Currently those modules are not built with nix.
daspk04
force-pushed
the
add-otb-9.0.0
branch
2 times, most recently
from
e83a4d6
to
dbdaf48
Compare
|
@jackyliu16 I did some more changes. Will it be possible if you could review one more time ? |
|
@daspk04 To be honst, I not a specialist in packing. But the things I could suggest is follow:
|
* an old version of itk with extra configuration required for OTB 9.0.0
Thanks @jackyliu16. I have formatted using the nixfmt-rfc-style.
As suggested by @SuperSandro2000 c.f, either override or local to the package I followed the second approach as it seemed easier and more logical to me, possibly can be done using overwrite but I'm still not sure how to do it for now😅 |
|
Hi @SuperSandro2000 , Will it possible if you could review it one more time ? I have formatted using |
|
Hi @SuperSandro2000 , I would like this to be merged so I would like to have your suggestion regarding the questions that I have asked earlier in the comments, if you could please suggest what changes are further needed for this to be merged. |
| optionals enablePython (with python3.pkgs; [ numpy ]) ++ (extraPythonPackages python3.pkgs); | ||
|
|
||
| otb-itk = callPackage ./itk_4_13/package.nix { }; | ||
| otb-shark = shark.override { enableOpenMP = enableOpenMP; }; |
There was a problem hiding this comment.
Why not enable openmp by default and drop the option?
There was a problem hiding this comment.
Thanks @SuperSandro2000 !
By default it is OFF c.f so I have kept it as it is.
| enableFeatureExtraction ? true, | ||
| enableHyperspectral ? true, | ||
| enableLearning ? true, | ||
| enableMiscellaneous ? true, | ||
| enableOpenMP ? false, | ||
| enablePython ? true, | ||
| extraPythonPackages ? ps: with ps; [ ], | ||
| enableRemote ? true, | ||
| enableSAR ? true, | ||
| enableSegmentation ? true, | ||
| enableStereoProcessing ? true, |
There was a problem hiding this comment.
Do we really need those options? or can we just turn them on by default and make things simple?
There was a problem hiding this comment.
Actually by default OTB has only core modules and all these options are OFF. They have mentioned in doc that incase one needs some module then one can turn on, but then that requires compiling again from source. I would prefer to keep these option as this is similar to as mentioned in doc, here I kept all ON by default (opposite from OTB) as compiling all takes a bit of time (~30min) incase one doesn't need some some module they can override.
Ideally I would prefer something like this in Nixpkgs so that one don't have to build or compile (possibly can be done later):
- otb (full)
- otbMinimal (only core)
- otbSAR (otbMinimal + SAR related modules)
- otbLearning (otbMinimal + Learning related modules)
- ...
That would be nice but the files are already pretty different and maintaining backwards compatibility might be a pain in the future. |
* init at an unstable version based on commit at 2024-05-25 as no more official release from 4.0.1 onwards.
|
Hi @SuperSandro2000 ! I have applied all the suggested changes. |
|
Hi @SuperSandro2000 ! Will it possible if you could review once more ? I have already applied all of your suggested changes. |
| nativeBuildInputs = [ cmake ]; | ||
|
|
||
| meta = { | ||
| description = "Shark is a fast, modular, general open-source C++ machine learning library"; |
There was a problem hiding this comment.
| description = "Shark is a fast, modular, general open-source C++ machine learning library"; | |
| description = "Fast, modular, general open-source C++ machine learning library"; |
| ''; | ||
|
|
||
| meta = { | ||
| description = "Orfeo ToolBox"; |
There was a problem hiding this comment.
| description = "Orfeo ToolBox"; | |
| description = "Open Source processing of remote sensing images"; |
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.