As I suggested on the call on software development best practices (7 jul 2020), it might be interesting to release the OCR-D modules also as conda packages. Since the application is a package manager and also a virtual environment manager, it could be used for:
1) Packaging OCR-D modules written in any language (not possible in pip);
2) Building cross-platform packages (Windows, macOS and Linux - RPM-based and Debian-based);
3) Installing package dependencies on a virtual environment, including system dependencies (not possible in a python venv).
It also supposedly resolves dependency conflicts better than pip.
The biggest problem as I see it is that the system dependencies should also be available as conda packages in order for OCR-D to be fully contained on the environment. It would work on a debian-based system without being fully contained as long as the dependencies are previously installed from debian packages, but then it would not be cross-platform (2) nor there would be installation of system dependencies on a virtual environment (3), making conda packaging pointless when compared to debian packaging, since debian packages are also language-independent (1).
cneud
commented
4 years ago
As I suggested on the call on software development best practices (7 jul 2020), it might be interesting to release the OCR-D modules also as conda packages. Since the application is a package manager and also a virtual environment manager, it could be used for:
1) Packaging OCR-D modules written in any language (not possible in pip); 2) Building cross-platform packages (Windows, macOS and Linux - RPM-based and Debian-based); 3) Installing package dependencies on a virtual environment, including system dependencies (not possible in a python venv).
It also supposedly resolves dependency conflicts better than pip.
The biggest problem as I see it is that the system dependencies should also be available as conda packages in order for OCR-D to be fully contained on the environment. It would work on a debian-based system without being fully contained as long as the dependencies are previously installed from debian packages, but then it would not be cross-platform (2) nor there would be installation of system dependencies on a virtual environment (3), making conda packaging pointless when compared to debian packaging, since debian packages are also language-independent (1).