[hprotagonist]

> Then there's the rigmarole around getting one of these environments to play nice with cron...

You pass cron the full path to your entry point. Where’s the rigamarole?

[jalons]

You've also got to include the pyenv shim instantiation. So now you've got something like

0 0 * * * /path/to/bash/script/to/init/pyenv && /my/path/to/poetry run /my/path/to/python.py -arg1

[Chiron1991]

Hm, haven't tried it, but doing this should be much easier:

0 0 * * * /path/to/interpreter/created/by/poetry/bin/python myscript.py

[EE84M3i]

Does bin/python in a virtualenv set PYTHONHOME correctly..?

[remlov]

Yes. And the answer by Chiron1991 is the proper way to do this since pretty much forever.

[EE84M3i]

Strange, this does seem to work with python3.8 on ubuntu 20.04 (the site-packages shows up in sys.path), but for me in a virtualenv bin/python is a symlink to the system python, so how does python 'know' what path to use? Is there logic baked into the interpreter?

I seem to recall that with python2.7 that calling bin/python in a virtualenv without activating the virtualenv did not used to "work" (i.e. it would use the system packages). Did this change at some point or is my memory just wrong?

[jalons]

Yes, if the python interpreter the poetry environment utilizes is in your $PATH.

[hprotagonist]

this is precisely correct.

[cbcoutinho]

If the path to your executable is fixed, just put it in the shebang and you're done - makes everything way more explicit at the cost of some dynamic behavior.

An anecdote: Homebrew uses this method for shipping python executables.

[im3w1l]

The "production version" of your script should be running in your system environment with system packages. pyenv and friends should be used for testing with different versions and making sure you don't accidentally depend on idiosyncrasies of your box.

The exception is if your python thingy is "the main thing" running on a server, i.e. your customer facing webapp.

My $.10 anyway

[jalons]

I tend to agree with you that pyenv|pipenv|etc shouldn't be used for actual production usage.

This of course leads to other issues to solve, now that your development environment doesn't actually mirror production.

[ses1984]

How do you package your entire pyenv as one or more system packages?

[im3w1l]

This isn't exactly what you are asking, but https://askubuntu.com/questions/90764/how-do-i-create-a-deb-...

[hprotagonist]

pyinstaller, shiv, pex, docker: depending on use case, any of these may be appropriate.