Packaging issues

[StanczakDominik]

I like to keep things up to date on issues (I forget stuff a lot), so I'll add what we discussed today (and some other minor issues I forgot to raise) as todo items:

• [x] Make pip install build an importable package just the way makefile aurora does (trial/error optimization and comparison of the two build processes, looks okay)
• [x] make sure pip install pulls the package dependencies (it didn't for me)
• [x] add basic CI for the build step
• [ ] add basic tests through based on examples/basic.py

---

Hey, great talk yesterday! :)

I'm 90% sure I'd be able to automate the installation process into a single conda install -c conda-forge aurora (assuming the name is not taken). The reason why it'd be conda forge is because that's where community built packages generally live, and the main Anaconda repo (the big default) does not really accept contributions.

Would you like me to try? :)

[StanczakDominik]

And I guess from there we could start working on a PyPI installation.

[fsciortino]

Hey Dominik! Thank you very much :)

You might be right about that, but it seems to me that one should be able to upload to Anaconda Cloud (see this). I actually pushed a previous package, but there's some issue that I'm running into with Aurora, which has a slightly more complicated directory structure. (NB: the "aurora" name is indeed already taken by another user, sadly, that's why I'm opting for "aurorafusion" -- but the package should still import as "aurora").

Most of the conda and PyPI setup for aurorafusion should already be done in this Github repo, but I'm running into issues during installations, apparently because the package .tar files are not unwrapped correctly. You can have a look at my most recent attempt here on Anaconda or on PyPI. If you try to download the package .tar file, you can see what it's supposed to look like, but when you try to install... for some reason it's not maintaining the package structure and that doesn't let the code be functional.

If you have time, I'd love to get your thoughts on what might be going wrong. Would you be free during the conference lunch break today? If so, I can send you a Zoom link.

Thanks for your offer to help! Greatly appreciated :)

[StanczakDominik]

Hey, is tomorrow okay with you? I present on PlasmaPy today after the lunch break (which, in the EU timezones, should be considered a walk-your-dog-before-bed break :smile:), and I'm probably going to be busy fretting about that :)

[fsciortino]

Certainly! Let's aim for tomorrow. Good luck with your talk, and thanks again for taking the time to open this issue and offer to help!

[fsciortino]

Hey @StanczakDominik, did you have another look at this packaging issue? It's OK if you're too busy -- in that case, would you mind just posting here the few lines that you were suggesting to modify, so that I can pick it up from there? Thanks for your help!

[StanczakDominik]

Hey, I would have already put it up if I could actually, you know, reproduce the improvements I saw before! I think what I did before - and didn't realize - was that I usedpip install -e ., so it didn't actually add the version file in the package's data.

Still, I'm working on it - expect a few incremental PRs once I figure it out :)

[StanczakDominik]

Since we're bound to the numpy version of distutils, I think https://numpy.org/doc/stable/reference/distutils.html (config.get_version()) may help us get the version file right. It could be that the pkgutils version I implemented was a horrible hack that worked for us at plasmapy in a completely different situation... I won't pretend to have more than a surface level of this :D I'll give this a read in a few hours and get back to it.

[fsciortino]

Since we've reached a decent packaging solution for the moment, I'll close this. @StanczakDominik if you ever have time/interest to help me to improve this, please do re-open and I'd be happy to look into this more.