Nice list. Plenty to try there! What are your thoughts on pipenv? I’m fairly new to python and coming from ruby pipenv seems very natural to me but it doesn’t seem to be widely adopted.
I haven't actually used pipenv. If you asked me 2 months ago, I would say: "don't use it, it's abandoned", as there was no release between 2018 and 2020.04.29. But it seems to be back on track again.
With my clients, I use requirements.txt + pip-tools to pin versions. That's an old-fashioned but pretty bulletproof solution. In my personal projects, I used poetry, and I liked it. But I would not use it in a commercial solution (unless the client insists, which never happened) - mainly because of the bus factor (it's still maintained by a small group of people).
Also, keep in mind that I write applications, not Python packages. For writing a Python package, I would go with Poetry (it takes away a lot of hassle with packaging, etc.)
Ah, OK. I saw a lot of places where people said it was the "right/standard" way of doing things going forward. I guess that could have been wishful thinking. My main use case is writing AWS lambda functions and I like the way I can define dev dependencies separately so they don't get packaged up with the final build and impact startup time. I've never been able to find a way to do that in a requirements.txt file though. Is there an ideomatic way to deal with this? Maybe a separate requirements file?
Your intuition is correct - it can be achieved through separate requirements files.
I usually have 4 of them (2 maintained by hand, 2 generated automatically):
requirements.in - list of packages that you want to include in the final build, e.g. "django". You can be even more specific: "django<3.0"
requirements.txt - pinned versions - this will be generated by the pip-tools, so you never touch this file by hand, e.g. "django==2.2.2"
requirements-dev.in- packages used by developers (not included in the final build), e.g.: "pytest"
requirements-dev.txt - pinned versions of packages for developers generated by pip-tools.
You add packages to the *.in files, generate the *.txt files with, let's say a Makefile command, and use them to install packages on the destination servers.
Nice list. Plenty to try there! What are your thoughts on pipenv? I’m fairly new to python and coming from ruby pipenv seems very natural to me but it doesn’t seem to be widely adopted.
I haven't actually used pipenv. If you asked me 2 months ago, I would say: "don't use it, it's abandoned", as there was no release between 2018 and 2020.04.29. But it seems to be back on track again.
With my clients, I use requirements.txt + pip-tools to pin versions. That's an old-fashioned but pretty bulletproof solution. In my personal projects, I used poetry, and I liked it. But I would not use it in a commercial solution (unless the client insists, which never happened) - mainly because of the bus factor (it's still maintained by a small group of people).
Also, keep in mind that I write applications, not Python packages. For writing a Python package, I would go with Poetry (it takes away a lot of hassle with packaging, etc.)
Ah, OK. I saw a lot of places where people said it was the "right/standard" way of doing things going forward. I guess that could have been wishful thinking. My main use case is writing AWS lambda functions and I like the way I can define dev dependencies separately so they don't get packaged up with the final build and impact startup time. I've never been able to find a way to do that in a requirements.txt file though. Is there an ideomatic way to deal with this? Maybe a separate requirements file?
Your intuition is correct - it can be achieved through separate requirements files.
I usually have 4 of them (2 maintained by hand, 2 generated automatically):
requirements.in- list of packages that you want to include in the final build, e.g. "django". You can be even more specific: "django<3.0"requirements.txt- pinned versions - this will be generated by the pip-tools, so you never touch this file by hand, e.g. "django==2.2.2"requirements-dev.in- packages used by developers (not included in the final build), e.g.: "pytest"requirements-dev.txt- pinned versions of packages for developers generated by pip-tools.You add packages to the
*.infiles, generate the*.txtfiles with, let's say a Makefile command, and use them to install packages on the destination servers.Awesome! Thanks for your help. I'll definitely try this as I feel like I'm swimming against the tide with pipenv.