Re: Avoiding PYTHONPATH - latest?

[Phil]

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.