Thanks again zimoun for your comments. zimoun writes:
> I am not sure to understand what you mean. Installing always means > “fixed at package@version”. I should miss something with your > workflow. So using pip in 'editable' mode installs your git clone via softlinks as a package. It doesn't really have a version - it's the code you're currently working on and will change every time you save a file without having to re-package. There is no equivalent to this in Guix - by design, of course. > This is a bad practise and should not be encouraged. All in all, you > end up with the big mess that Guix is trying to fix. What I like about 'pip install -e' is that you are testing the actual package that end-users are going to install - without the hassle of explicitly installing it. I could instead run my unit tests against my git clone, but then you're not testing what you will deliver, you're testing the source code that will be packaged, not the package itself. The unit tests may fail if run on the package itself. The way around this in Guix, I imagine, is to rebuild a Guix package containing your own Python code each time you want to test it and then have the unit tests run as part of that package definition. This is what I'm going to try to do, but it might end-up being a fairly custom setup which may not integrate so well. > > For example, I am using Emacs and before I was using ’use-package’ which > allows to locally tweak the packages that I depend on. Then, I wanted > to do the same with Guix. At the end, it is wrong. The right thing is > inspect the package and if you need to fix, do “guix build -S <pkg>”, > fix and create a variant using package transformation, for instance. > This way, you have something reproducible, easy to share and/or deploy. > IMHO. Yes this makes total sense when I'm installing someone else package rather than developing my own using pip. > We discussed at the recent Guix Days that documentation “Getting > starting with X” is lacking–where X is Python, R, C, Haskell, etc. Yes this would be great - I'm happy to chip away at it, and even change my setup to make it more Guix-sensible.... but as a launch-pad to get people setup quickly with an explicit list of do this, avoid this - would be great! > > Feel free to send a Cookbook recipe [1] about your Python setup. :-) > > 1: <https://guix.gnu.org/cookbook/en> Will keep this in mind - once I have my setup more Guix-complaint. I'd be keen to get feedback on it too - as per my last e-mail the Python community have a wide range of development setups, so it will probably be community effort to write a cookbook that caters to, or at least rationalises the various approaches that work in Guix.