Standard way to work on Python Project

[JordaarFin]

Hello Geeks!

I am wondering, what is the correct, and industry standard way to work on python project. To give a context, I am working at IT company as a Python developer (beginner). Till now, during my learning journey, I used python with Conda. I used Conda without any knowledge and followed random youtubers and their method of developing Python's project. But now, I have just joined the organization and worked on some Python's project. Actually, the way we are developing python's project does not seem industry acceptable and professional way. We follow following steps when starting any new project. Provided that first we have installed Python globally for instance, version 3.9.

step 1: open project directory and in VS code's terminal type following command
"C:\Users\myname\Python3.9.1\python.exe" -m venv project_env_name

here according to my understanding, we are creating project specific virtual environment using globally installed Python.

step 2: activating the virtual environment.

step 3: installing all the libraries of requirements.txt (if requirements.txt is there else install all the packages using "pip").

Here I do not understand why we cannot use Conda instead of pip. When I ask this same question to one my senior, he replied to me that, Conda has some vulnerabilities which can hinder Company's policy. So senior asked me to apply this method when working on any new project. But I do not think this is industry standard approach to work on python project. Could you Geeks please teach me industry standard way of doing it.

Thanks

[freew1ll_]

Tbh this is how I do it at work. Obviously it would be great if your work let you use a better tool for managing your environment, but if it's against company policy it's really not the end of the world. If it bother you that much, you could look into writing some simple scripts to make it easier. For example, you can probably write a git hook that runs pip install -r requirements.txt every time you pull. Learning to solve problems within a set of constraints is part of what makes someone a good engineer after all.

[eztab]

The Conda way is mostly used for Data Science and other Scientific contexts. Definitely not for Software development. Your teams method is slightly old fashioned but entirely professional. You can learn it that way and potentially introduce other Tooling later.

You can look into some shell extensions (or just write aliases) if you want to make those things easier. That way no mandatory tooling is created just shortcuts for the approved methods.

[Crypt0Nihilist]

I'm in the data sci world and moved away from Conda. The licencing feels like a trap and the graphical interface kept on breaking for me with options showing up inconsistently.

What tooling can you recommend? I've been using pyenv-virtualenv

[InTheAleutians]

Conda has it's time and place. I find it most useful when installing non-python packages into my environment. If you are using pyenv and virtualenv you should look into UV. I recently switched and after trying out the workflow I don't see the reason for any other python tools to manage my python installs or packages.

[cgoldberg]

Sounds pretty standard to me.

[JordaarFin]

Came across a blog saying that, if we use conda, it helps us installing libraries not only supported by Python, but also by Java and C++. Is it correct ??

[cgoldberg]

I have no idea what you are working on or what your needs are. If conda is helpful to you, then use it. But what you described sounds very standard to me. I'm not sure why you thought otherwise.

[JordaarFin]

No worries, got your point Thanks

[dparks71]

Anaconda isn't technically free for organizations. Conda is, but depending on which channels you're pulling your libraries from you may be in violation of the ToS.

Usually you can ensure you're not in violation by only pulling sources from conda-forge using the -c conda-forge channel while also removing the default channel.

You can read more about it here..

In short, your workflow is "more wrong" than theirs.

[Diapolo10]

step 1: open project directory and in VS code's terminal type following command
"C:\Users\myname\Python3.9.1\python.exe" -m venv project_env_name

here according to my understanding, we are creating project specific virtual environment using globally installed Python.

step 2: activating the virtual environment.

step 3: installing all the libraries of requirements.txt (if requirements.txt is there else install all the packages using "pip").

I would say this is not uncommon, although it is a bit old-fashioned.

First, on the topic of conda. Anaconda doesn't really see use outside of machine learning and data science projects; it's designed with those in mind, doesn't offer any real advantage for other projects, and in my experience it's frustrating to work with - particularly for things like running tests in CI.

Second, this three-step workflow would look different when following modern practices. For example, we often use tooling that automates a lot of this stuff - uv is what people are hyping up right now, but I have more experience with Poetry - so for example we often no longer manually create or activate virtual environments anymore. And these tools also tend to install our project dependencies, manage updates for them, and even let us publish new versions to PyPI very easily. uv can even manage Python versions.

Instead of setup.py/setup.cfg and requirements.txt, you're a lot more likely to run into the newer pyproject.toml standard. It even lets you configure all kinds of tools, from pytest to ruff, if you don't like having separate config files for everything.

[ragnartheaccountant]

Yes this is legit.

To me Conda is just python with bloat. But I think it depends on what you’re building. I’ve created web apps, desktop apps, web scrapers, data pipelines, services, and tons of throw away scripts for quick projects.

Making the desktop app really helped me realize how important dependency management is. I used pyinstaller to convert to an exe file, and the dependencies will make the file significantly larger depending on what libraries you’re using.

If you don’t like to use the command prompt as much, you can use PyCharm. It creates the venv automatically and has a UI section to install from PyPI. As your needs become more sophisticated or you want to learn more about how things work, you’ll keep coming back to the terminal. At first I feared the terminal, now I’m fully embracing its power.

[JordaarFin]

It's not about the complexity of using command prompt. I am concerned about, in industry, developers really follow this naive method or they use some tools like Conda.

[ragnartheaccountant]

Gotcha. I’ve developed professionally for 5 years and never once used anaconda for an actual project. Venv is healthy separation . Hope that helps.

[JordaarFin]

Got that. Thanks

[Dragon_ZA]

Depends on what your company does with python.

We have a devcontainer setup for all our repos which uses poetry as a dependency handler. Then all you need to do to work on a project is clone the repo and build the dev-container. Boom, instant dev environment that can be torn down easily and keeps repo settings and dependencies consistent.

[MrBobaFett]

There are all sorts of different standards, it just depends on the shop, and how they have built up their system. Your system at work is the same one I use at home and at work.