Suggestion to upload the calcam to PyPI.

[munechika-koyo]

I would suggest uploading this package to Python Package Index in order to install it with the pip command. I think calcam is a very useful package and use it in my original one, so t is more preferable to list calcam as a dependent package and manage it with pip.

What would you think of this idea?

I would be able to help with this modification using like setup.cfg, pyproject.toml, etc. if necessary.

Thank you in advance.

[ssilburn]

Hi! Yes, originally I didn't package it for PyPI because the dependencies were very tricky so it didn't make much sense, but more recently the dependencies are mostly easily available on PyPI also so this should be more feasible! If you have time and know how to do this, feel free to go for it and put in a pull request! Otherwise I can have a look at it for the next update.

[munechika-koyo]

Thank you for welcoming my contribution. I am developing the packaging system according to setup.cfg config.

In addition, I am aiming at producing wheel file and upload to pypi.

[ssilburn]

Hi, Thanks! Although I already mostly worked on this - sorry I should have posted here so we don't both do the same work! If you look at the head of the master branch, I have made setup.py suitable to build source distributions.

I also uploaded it to TestPyPi to test it will work OK - https://test.pypi.org/project/calcam/

When 2.9.0 is done (just a few bugs left to fix), I was planning to put this source distribution on PyPi. If you manage to get it to build wheels that will work across a range of platforms I'm happy to add that in, but I couldn't think of a way to properly handle the dependencies, e.g. requiring EITHER opencv-python OR opencv-python-headless, and EITHER PyQt4, PyQt5 OR PyQt6. These things can be handled with some logic if setup.py executes, but building wheels will mean setup.py does not run at install, so my thought was, distributing it as source is the best way to make it easy to install on the widest range of platforms.

Edit: I also added a GitHUb action which should build a source dist and upload it toPyPi whenever a new release is made on GitHub.

[munechika-koyo]

I am just wondering why we do not choose one option for such a dependency. Is it not allowed to set specific dependencies for example "open-python-headless" and "PyQt6"?

[ssilburn]

It's to make it better compatible with a wide range of platforms / environments. For example I have tested / used it on Windows, WIndows using Enthought Canopy, Scientific Linux on the JET data analysis machines, and Ubuntu (and know people who use it on Mac OSX). And the availability of, for example PyQt6 is different across the different platforms. So keeping multiple options for the dependencies allows it to install easily on a wider set of systems.

Also there are some situations where people may be using Python installations managed by a different external package manager, which provide certain versions of PyQt, OpenCV etc, which are not recognised or managed by pip. In this case it is good to have custom logic in setup.py for checking the dependencies, because otherwise the pip install can fail even if the dependencies are met (for example this happens on our JET scientific linux mcahines).

If it's being installed on a fresh install on a machine that the user controls fully, I agree it would be easier to stick to a single version. The approach of having "fallback" dependencies is for when this is not the siutation, e.g. installing it on a python installation administered by someone else, or on a platform with different packages available / different package management etc.

[munechika-koyo]

Thank you for your kind reply. I understand there are a lot of platforms to use calcam. (However Canopy already reached End Of Life so I think we should not use it....) The another package manager you mentioned is Anaconda isn't it? I also use this package manager so I am thinking of it, but I am not familiar with the way of making packaging system for anaconda repository.

According to PEP621, the python packaging procedure is been integrated into one file : pyproject.toml, and I think it is required to follow the PyPA rules in order to establish the important position in the at least fusion OSS community.

Anyway, I will try to look for how to resolve the dependencies' issue.

[ssilburn]

Thanks. Yes good point about Canopy, sorry. Anaconda is one example yeah, I think there are other examples too - for example I think it's still true that on Ubuntu the system package manager can install some python packages which are transparent to pip, so could result in installation failing for "false" reasons.

I definitely agree it would be best to do things according to the PyPA best practice, but I would prefer to prioritise compatibility and ease of installation for users first - particularly because many of the target users are diagnosticians / physicists and not mainly software developers, who I expect will care more about ease of use than whether it conforms to software best practices.

For now I'll put the source dist on PyPi, but I'll leave this issue open so we can continue to discuss and work on it - please post updates if you find a better way! If you come up with something I'm happy to try testing it on a few different platforms to see how well it works.

Also I would guess that soon pip will drop support for direct installation completely, so we'll need to find a better solution by then, certainly.

[munechika-koyo]

Thank you for leaving this issue. Considering the users who want to use only its GUI feature, what about creating standalone software or executables? Using cx_Freeze or pyinstaller would enable us to achieve it easily. cx_Freeze can generate .msi installer for windows machine as well.

Personally, I would like to apply anaconda compatibility because many data scientists including me manage packages with conda. So, I will try to look into how to handle it a little.

Also I would guess that soon pip will drop support for direct installation completely, so we'll need to find a better solution by then, certainly.

I have never heard of it. Do you mind if I ask you to tell me which web page is written about it?

[ssilburn]

I'm now finally going to close this issue because in release v2.11 Calcam now uses pyproject.toml and does things in a more pep-compliant way. As on the other issue, please can you open a new issue for anaconda distribution?