Make version of main dependencies easily accessible in distributables

[butlerpd]

For debugging purposes it would be helpful to be able to easily see the version number of all dependencies uses. This may be a lot but we could start with at least sasmodels and bumps perhaps? It could probably be added to the about box or some config file during the build process. Would need to verify that the distributable build (exe and dmg builds) carry this info as well as when doing local builds

[Caddy-Jones]

Hi @butlerpd, I've had a look at the issue, and was wondering if you could clarify something for me.

Are you thinking of having SasView document the current version number of all the dependencies currently installed within the virtual environment upon running SasView? Similar to running pip list/freeze, but outputting it to the config file or something.

Or is it better to have a list of dependencies created during installation by scanning through the SasView project scripts? In theory that list can then be used to set up the anaconda virtual environment using dynamic requirements for SasView, but this is probably overcomplicating things

[Caddy-Jones]

Or maybe both?

[butlerpd]

humm... you are way ahead of me @Caddy-Jones 😃 The issue was raised because, despite the yml files, local developer machines tend to have different versions of packages and, as was discussed at the last call, even github actions and the jenkins build machines use different versions of the dependency. Further, because of the hardcoding of the dependency versions on the Jenkins builds, it happens not infrequently that new features end up breaking the installer builds. Then, for those of us on the help lists trying to respond to problems in different release versions of SasView it is sometimes useful to know what version the build machine had at the time the release was made. Finally, for FAIR and Opent data etc initiatives, being able to identify which versions of dependent packages were used would probably be a good thing for transparency (e.g. the version of SasView used for the analysis was based on Scipy 1.5.2 which is known had a bug in the Legendre calculation - I'm making that up of course but hopefully makes the point 😃

I will admit however that I do not understand enough myself to figure out which of your scenarios above would be the best approach without digging a bit. Hopefully, the explanation of what I was suggesting we need to achieve helps? Otherwise maybe @rozyczko, @wpotrzebowski or @krzywon might be able to answer better?

[andyfaff]

even github actions and the jenkins build machines use different versions of the dependency

If both of these build systems make a new environment (venv or conda), then using a requirements.txt or an environment.yml should mean that the same dependency versions are used.

[lucas-wilkins]

I think this will be resolved by #2177

[lucas-wilkins]

@butlerpd is this resolved by the dependency viewer?

[butlerpd]

If it were fixed and then re-activated yes I think. But currently it is disabled because it is not 100% working.