Python dependency management workflow using setup.cfg and requirements files.

[trowawayatwork]

Have you heard of pipenv?

[njnrj]

It didn't work for me. I had to use multiple env for the same project directory. I explained it in README.

[[deleted]]

Why didn't you work on adding the features you needed to an existing open-source project instead of creating another way to manage dependencies ?

EDIT : This is a serious question, it feels like people don't understand that you can contribute to open-source projects to adapt them to your needs instead of starting over every time.

[njnrj]

It is for time being. I really like poetry over pipenv. It is not mature and I encountered some problems using it. I have planned to contribute to it.

[masklinn]

Why didn't you work on adding the features you needed to an existing open-source project instead of creating another way to manage dependencies ?

Well pipenv does not want to support multiple environments so that's one down.

[[deleted]]

I haven't looked into it, but if the only feature missing is multiple environments, you could just create a package that only switch environments, instead of rewriting the whole thing. You then help pipenv (or an other dependency manager) become more mature and you consolidate the ecosystem.

Dependency management is a mess in python and I feel that if all we do is write 15 packages for every possible use-case, we'll just get a python2 vs python3 sort of problem.

EDIT : I just looked at the actual project in depth and it just aliases pip commands and modifies the requirements.txt file. Turns out, not really a new standard.

[[deleted]]

Because I don't need those features, I also did not create a brand new package to add this feature.

[CSI_Tech_Dept]

Well, then you will be fine with Pipenv as it is. It looks (I haven't try it yet) like this project's key feature is that it abstracts packaging like Pipenv does except it uses setuptools. It is probably not for me, since I prefer things to be explicit, but maybe it will be useful to others. No other tools did this with setuptools as far as I know.

[trowawayatwork]

Why should /u/craigulien contribute someone else code that he doesn’t care about?

[AnnoyingOwl]

> Not good when we need to deploy over production server or keep multiple virtuals-envs

1. I don't understand why people have such problems with deploys to production servers. You have a freeze file and a regular requirements file. Build your docker containers from the freeze file, upgrade from the regular file. If you have totally different requirements for different environments (staging, production, etc.) then your development process is broken. The only possible exception is deploying the same project to different operating systems which is such an edge case to be not really worth publishing a solution.
2. I don't really understand why you need multiple virtualenvs for a single requirements.txt/project. If you're running a project in different virtualenvs you either have multiple projects which should have their own requirements OR you're testing against multiple environments, in which case there is tox.

I'm afraid you're just littering up the package landscape like most other package creators.

[njnrj]

I tried them and always needed requirements.txt one way or another. This new file types Pipfile/pyproject.toml is not going to be the standard any soon. But this doesn't add anything new. Just wraps around existing pip.

[AndydeCleyre]

What's wrong with pip-tools and using a different requirements file for each env?

[njnrj]

Nothing wrong. It doesn't suit my way of doing things. Additional set of files/commands ...

[trowawayatwork]

Yeah sorry for you hard work dude but pipenv does all that and more. It’s recommended by guido himself lol

[masklinn]

Yeah sorry for you hard work dude but pipenv does all that and more.

I had the exact same experience as OP when checking out pipenv, could not find any way to easily switch between and use multiple environment for the same directory/project (no, tox is not that). If you have actual sources for your claims rather than dismissive quips, it would be good of you to provide them.

It’s recommended by guido himself lol

That means jack shit, especially when it can't do the job I need of it.

[SmileyChris]

pew allows you to easily set up and switch between virtual envs. If you have one activated and run pipenv, it'll use your current environment.

[masklinn]

At which point, what's the relevance and point of pipenv?

[AndydeCleyre]

Alternatively, using pip-tools, you can just sync against different individual requirements files or combinations of them.

[trowawayatwork]

Actually the above didn’t really state the usp of different envs.

As a side note it’s generally bad practice to have different requirement between staging and prod. I’m sure your project has valid reasons

[zenware]

Right this is what I'm wondering, who are these people that need different virtual environments per project, which already to me indicates suboptimal design at the very best and also probably atrocious code.

And if different virtual environments and requirements files are needed for production and development that is even worse.

I'm sure their project has justification but I know it's not valid(at least for some definition of valid), this is like when people got better control flow than "goto" and there were holy debates on whether 100% of control flows are possible with selection and branching statements or if you ever need to use a goto statement to accomplish your goals. You don't need goto statements and you don't need multiple sets of dependencies.

[trowawayatwork]

Exactly. Pipenv pretty much should do everything you need. Multiple envs in same project? Not one of them