Questions about the project.

[thebashpotato]

Hi there, just wanted to say this project is extremely interesting, I had no idea until now that NASA freely distributes data and software via the NAIF Spice Toolkit. Your goal of a more modern implementation in Rust is very exciting. With that being said, I have some questions.

1. To be useful on such a project it seems clear one must understand the original software,
   so I have been following the official SPICE tutorials. Other than that is there anything you recommend for someone who doesn't come from this field (my background is Computer Science, and I work in the Power and Optics industry)?

2. I've noticed there are Python bindings via the PY03 crate, and also an empty anise-cpp folder, which I am assuming is for future C++ integration. Do you have a plan for C/C++ bindings? I'm experienced with the
   Interoptopus crate, allows for Python, C, and C# bindings to be generated from Rust code. The resulting C code would/should be wrapped in a modern C++ header-only library for distribution. So there is a bit more work going that route, but you do get support for 3 languages. However, I am unsure of your design ideas or plans.

3. Are there any plans for packaging the GUI, (deb, rpm, msi)?

Anyway, thank you for your time.

[ChristopherRabotin]

Hi Matt,

The SPICE tutorials are definitely a good start. If I remember well, they're mostly theoretical in that they explain stuff but don't provide many exercises. I've written some practical tutorials for the Python interface of ANISE here: https://github.com/nyx-space/anise/tree/master/anise-py/tutorials. I've started documentation on the website, but it isn't fully complete: https://nyxspace.com/anise/ (is documentation really ever finished?).

You're right that the Python bindings use PyO3, which I've used before in both Hifitime and Nyx. I haven't heard of Interoptopus before. Someone has just started working on the C++ bindings using the cxx crate a week ago, but I don't know the state of the art of C++ bindings to Rust crates, so I'm open to any suggestion. If you're interested in writing those C++ bindings, I can put you in touch with that other person and I'm happy to support where I can.

Concerning the packaging plans, I haven't really thought that far yet to be transparent. On Windows, it has been a pain to have to "unblock" the executable before running it because the binary isn't signed , so if an msi file would solve that, I'm all ears. This is my first time writing a GUI in fifteen years, so I surely have lots of learn. For the Linux distribution of the executable, I was thinking that a Flatpak might be easier to handle, and it seems like that's where the Linux world is moving toward with Fedora 40 and Opensuse Aeon. But same, I'm open to other ideas since I'm new to distributing executable software.

All the best,
Chris

[ChristopherRabotin]

P.S.: I've started using your crate again! master...191-bis -- might be a few weeks before I publish the next version.

[thebashpotato]

Nice job on the tutorials and examples! I will go over those once I'm done with the more theoretical NAIF material. And no documentation is never done, but it seems you've put alot of effort into it.

The cxx crate is solid for sure, the only potential issue I can see is the project will have 2 specialized bindings libraries that will need to be maintained seperately and there will be no C support. However, if that is the goal than it isn't a big deal. Perhaps a discussion with the programmer implementing the C++ side could be had.

As far as packaging goes, I do agree that flatpak is the future. The rust flatpak crate is unmaintained and out of date, but that isn't a big deal. I can just use the offical docs and manifest file approach, so I'd be happy to take on the responsibillity of flatpak.

As far as Windows goes, the msi installer does solve the untrusted binary issue (along with the Sign Tool), and supplies the classic Windows intaller experience that most end users have come to expect. And if so desired can be added to the Microsoft store. The cargo-wix crate will make short work of this. I've used this to package rust software for Windows at work, so I'd be happy to take on this as well.

As far as MacOS goes, I have no experience here, nor do I have a Mac machine to test on, so maybe backlog that idea until someone comes along.

The cli could also be packaged quite easily, for Linux flatpak wouldn't be a good option for a cli tool. But cargo-deb makes this a breeze, and Fedora supports an offical crate rust2rpm which also makes packaging rpm trivial (this approach could also be used for the GUI, since its actually very easy to do, the crates do all the heavy lifting). I would also be fine taking this on.

All of the packaging would be ran in a Github action and auto uploaded to the releases page. So once its in place maintenance would simple or virtually non-existent.

Hope I'm not overwhelming you haha, just wanted to put all the options out there.

Also, are there anyother features planned for the GUI? Or is it mainly to load data from a file and display in a table?

Glad to see my crate is back in use, it's getting more attention than I expected, guess I'm going to have to add more themes to it!