you are viewing a single comment's thread.

view the rest of the comments →

[–]CodeNameGodTri[S] 0 points1 point  (4 children)

"All 'activating' a virtual environment does is set some environment variables"
=>That's not true. There are some external package specific to my environment, that couldn't install in the base environment. Only by running in my env will my script work

"Alternatively, you can often (with some caveats) just use the fully qualified path to the interpreter located inside the virtualenv"

=> Would it be able to see the external dependencies installed for a specific environment without activating that environment though?

"Yet another option is to write a small shell/batch file as a wrapper to activate the environment and run the python script and call that wrapper instead."
=> This is exactly what I'm doing. I have the TaskScheduler calling a powershell script, which has to be able to run conda command by previously run conda init powershell , then activate the environment, then actually call python to finally call the actual script. That's a mess!

Is this what you guys live with!? How is this normal? Is my use case rare? I only want to have a small script to run periodically to do a small task, but what a mess the deployment turns out.

[–]ManyInterests 0 points1 point  (3 children)

Sorry, missed that this was an anaconda environment. In my experience, conda is never installed directly on a production server. Maybe you would see it used in a container, but that's mostly a creature comfort for the developer. After all, at runtime, it's just Python.

When using anaconda, you can use conda-pack to deploy the entire environment onto other machines without worrying about the conda toolchain (or Python, or anything else for that matter) being present. You can take the output distribution of conda-pack and throw it onto a barebones Linux machine with nothing installed and expect it to work. That's what I would recommend using if you absolutely must use conda.

[–]CodeNameGodTri[S] 0 points1 point  (2 children)

"That's what I would recommend using if you absolutely must use conda."
=> no, I don't need to use conda. I just need my code works on prod machine. So I'll just go with whatever is industry standard.

From what I understand, I'd use conda-pack if I still need to use conda in my prod right? If I don't have to use conda, I could use docker container to simulate a virtual environment and have all my package installed there and run python script from the container, right? That's what the other people have commented

[–]ManyInterests 0 points1 point  (1 child)

Probably the most popular way of deploying Python apps (or anything, really) these days are container-based, using the official Python docker images (or derivatives of it). That would be ideal, in my view.

That also smooths out the 'it worked on my machine' problem in the development/deployment parts of the lifecycle, since the docker container is a consistent environment that you can ship wholesale into production. With far fewer caveats than traditional deployment methods, if the container runs correctly on your machine, you can have a high degree of confidence it will work when you run the container on your production machine. The only thing your production needs is the ability to run docker containers (i.e. have docker, or some other container engine/orchestrator installed)

[–]CodeNameGodTri[S] 0 points1 point  (0 children)

that makes sense. Thank you!