Recent searches
Search options
I'm interested in knowing how many environments people typically create for a project, and when you have more than one, what differs between the environments? (I will explain why I am asking this and my last poll, I promise).
@brettcannon multiple envs; different application deps; different system deps; sometimes different architectures targets, etc.
i still haven't figure out how envs work.
@brettcannon mostly I use tox now, for all of those purposes
@doughellmann @brettcannon I learned so much from #pymotw, and now I help maintaining #tox, and so the circle is complete 
@doughellmann and tox/nox give you an environment to potentially use directly as well when needed, so I think they could hit a sweet spot if they were easy to use directly when you needed to (which is an idea I have for the Python Launcher for Unix)
@brettcannon yep. I often define one without a command set so I can get a clean env with tools and deps to run stuff by hand for experimenting
@doughellmann @brettcannon In case you haven't been aware, there is the `tox devenv` command, which just creates an env for experimenting - though, afaik, you'd need to install additional tools via pip, e.g. pdbpp
https://tox.wiki/en/latest/cli_interface.html#tox-devenv-(d)
Shai Berger @brettcannon
I picked "different Python versions", but sometimes it's "different Django versions", and sometimes different Python/Django versions require different versions of other packages (usually one can upgrade a 3rd-party to a version which supports both versions of your main infra, but sometimes you don't want to because it comes with other changes, and sometimes the 3rd-party really supports only one version, like Grappelli used to do with Django).
@brettcannon in the past multiple envs with multiple python versions. Now multiple envs with multiple python versions, for different architectures because of Apple M1 chips adding to the chaos.
@brettcannon I vary between option 2, and a shared pool of venvs (different versions, same deps) that are shared between multiple projects.
@brettcannon We have one case where we have a few different 
Django projects in a monorepo and run them all often, so we think of the monorepo as one "project." We tend to have an env for the overall project task management (like triggering deployments of apps and the like) and then an env for each Django project.
We're starting to break that monorepo up, though.
@brettcannon Our software delivery system is unusual in that a single environment does not define the universe of software that it deploys. Instead a single software deployment is an amalgamation of many environments. Running a tool or process may jump through many of these environments.
Therefore our more complex tools use venvs in a similar pattern. Multiple venvs are created during development, and a layer of our software delivery system combines these into a "mini universe" for development.
@brettcannon usually one venv per project.
When more than one, the options are:
- multiple versions of Python
- nox / tox
- windows / WSL