EranOfek / AstroPack

Astronomy & Astrophysics Software Pacakge
Other
17 stars 4 forks source link

Do we have a permanent `version` function for AstroPack which I can use? #455

Closed EastEriq closed 3 months ago

EastEriq commented 4 months ago

Context: https://github.com/PolishookDavid/LAST_OCS/issues/28

Problem: record together with the images observed the version identifiers of all software components which contributed to the process. Among them, we should store the version/tag of Astropack in use for acquisition.

For the various classes I maintain, which inherit from LAST_Handle, I have created an utility function https://github.com/EastEriq/LAST_Handle/blob/mastrolindo/%2Bobs/%2Butil/%2Btools/getgitversion.m, and solved the problem for all my instument and abstract classes. I'm just missing AstroPack.

It will be trivial for me to call such a function also against AstroPack on creation of unitCS, so to store also that key. For that I would need an absolute path to a file of the AstroPack repo (robust to all vagaries of installation, perhaps derived from the startup script), or the name of an AstroPack function which is immutable throughout the life of the universe (I could use which, i.e. which('celestial.time.julday')). What would you suggest?

EranOfek commented 4 months ago

AstroPack version is stored in proc images by pipeline

On Sun, 9 Jun 2024 at 18:38 EastEriq @.***> wrote:

Context: PolishookDavid/LAST_OCS#28 https://github.com/PolishookDavid/LAST_OCS/issues/28

Problem: record together with the images observed the version identifiers of all software components which contributed to the process. Among them, we should store the version/tag of Astropack in use for acquisition.

For the various classes I maintain, which inherit from LAST_Handle, I have created an utility function https://github.com/EastEriq/LAST_Handle/blob/mastrolindo/%2Bobs/%2Butil/%2Btools/getgitversion.m, and solved the problem for all my instument and abstract class. I'm just missing AstroPack.

It will be trivial for me to call such a function also against AstroPack on creation of unitCS, so to store also that key. For that I would need an absolute path to a file of the AstroPack repo (robust to all vagaries of installation, perhaps derived from the startup script), or the name of an AstroPack function which is immutable throughout the life of the universe (I could use which, i.e. which('celestial.time.julday')). What would you suggest?

— Reply to this email directly, view it on GitHub https://github.com/EranOfek/AstroPack/issues/455, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJUQ4M4NSYFO6AQWVVRNULZGRZGBAVCNFSM6AAAAABJA7NRU6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2DEMZUGE3TOMI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

EastEriq commented 4 months ago

And that is not good, because it can be different from the version of AstroPack which acquired the images. No? Haven't we just worked with acquisition on dev1 with pipeline which needed to be on v2.1? Haven't we just committed today a fix to astropacK which affected the application of the pointing model to the acquired images? Will it never happen that you reprocess a raw image with a newer version of AsTroPaCK?

EastEriq commented 3 months ago

As per https://github.com/PolishookDavid/LAST_OCS/issues/28#issuecomment-2157677475. Closing the ticket here.