0

The build process for my python package requires creating a virtual environment and installing the package into venv on a server, running tests, then copying the files and venv onto another server. My setup.py has a console script entry point:

setup(
    ...,
    entry_points={
        "console_scripts": [
            "foo = mypackage.main:main",
        ]
    },
)

When I try to use the console script on the server, it cannot find the executable because it was installed into the virtual environment on a different server.

I tried to set the executable to use a relative path in the setup function options keyword with the key build_scripts, executable.

How can I ensure that the console script uses the executable of the virtual environment that is activated?

ptatulea
  • 25
  • 4
  • 2
    Besides creating a venv from ground up again, there is a tool named [virtualenv-tools3](https://pypi.org/project/virtualenv-tools3/) for this kind of work. A better explanation for everything can be found in [this video](https://www.youtube.com/watch?v=iZlgLrWed1I). – Clasherkasten Jun 07 '23 at 17:00
  • @Clasherkasten The video is the exact scenario thank you for pointing me to it. It seems like without modifying the virtual env with some tooling there is no alternative but the other answer which is to change the build process. Thank you! – ptatulea Jun 07 '23 at 22:05

1 Answers1

1

I might not be 100% grasping the situation, but one caveat that I do know about python venv's is that they cannot be migrated to a different machine (easily) because there exist hard coded paths within the venv itself to the specifications of the machine it was generated on. What I've ended up having success with is 1) pulling the modules out of the original venv as a requirements.txt 2) make a new venv on the new machine 3) reconstitute the original venv using the generated requirements.txt file from before. Here's the thread I used to figure out how to do all that: https://stackoverflow.com/a/49251593

Sand
  • 198
  • 11
  • Hi, that's a useful suggestion thank you. I could create a new virtual environment on the server after the copy but that does involve running a few steps of the deployment again. Unfortunately I'm not sure that there is any good way around this. Thanks for the input. I will mark as accepted if there is no other alternative. – ptatulea Jun 07 '23 at 16:50
  • @ptatulea yeah I had a similar scenario awhile ago, had to backtrack a bit. I'm under the impression that Docker is a much better alternative to pyvenv's because it allows you to copy an environment and deploy it in one step, but that of course requires you to have Docker set up (.. and be familiar with how to use it). The process I linked/mentioned is a couple steps but after the first few times I did it it was pretty painless and I was able to successfully deploy applications onto several machines with minimal headache. Let me know if it works or if there's any other issues! – Sand Jun 07 '23 at 16:53
  • 1
    Clasherkasten linked a good video with the exact situation I was describing and there is some tooling that can help, but I think I can accept your answer because without modifying the paths in the virtual environment it seems that there is no alternative but to change the build process (probably best if one can do that). – ptatulea Jun 07 '23 at 22:06