new feature: add ":pre-initialize-fn" function which does python package managent using "poetry install --sync"

[behrica]

``see here for details: https://clojurians.zulipchat.com/#narrow/stream/215609-libpython-clj-dev/topic/poetry.20install.20--sync

I can do a PR, if you are interested

This would be full optional, and triggers only if specified inside python.edn:

{:python-executable ".venv/bin/python" :pre-initialize-fn libpython-clj2.python.poetry/setup!}

[cnuernber]

That design looks fine - PR is welcome :-).

[behrica]

I come back to this and was wondering if we should use "uv" instead of "poetry". It seems that 'uv' is recognized by lots of people as superior compared to other python env managers.

It supports as well a "sync" cli command, so could work the same way as described above

[aaelony]

+1uv is amazing (along with everything Rust)On Dec 25, 2024, at 07:52, Carsten Behring @.***> wrote: I come back to this and was wondering if we should use "uv" instead of "poetry". It seems that 'uv' is recognized by lots of people as superior compared to other python env managers. It supports as well a "sync" cli command, so could work the same way as described above

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jjtolton]

For some reason I thought we'd implemented this already.

Personally this is why I think it would be best to make the :pre-initialize-fn be user-defined, to execute virtual environments, set environment variables, etc. Package managers have a tendency to change over time. I still use boring old virtualenv.

I'm not really in favor of trying to support package managers within libpython-clj directly, that could be a lot of work -- |python versions| * |package managers| * |operating systems| etc. We don't have the resourcing to test on multiple operating systems, versions, and package managers, so my guess is quality would suffer. I'd be open to suggestions.

However, a general :pre-initialize-fn that allowed users to do what they want wouldn't be so bad. @behrica I've seen you write some pretty sophisticated Docker projects in the past -- curious what would be your reasoning for wanting a :pre-initialize-fn when you could do it like this?

[behrica]

I had the same impression, there are way to many ways to manage a venv. I do agree as well that devcontainer allow as well to do something similar.

Nevertheless I like the idea, that it is the "jvm" start which makes sure that my venv is in place, so I cannot forget it....

But we can leave it for the user, indeed.

[behrica]

we even document it sufficiently:

A :pre-initialize-fn could for example shell out and setup a python
  virtual enviornment.

So I will close the issue here.