91–100 of 325 posts
Earlier quoted context omitted.
He talks about maintenance and making releases. Otherwise people will still deal with bugs in the "current" release that have been fixed in the master branch for a long time.
That would be mismanagement (and annoying of course), not "dead" I would think?
I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools
I recently switched from Poetry (to which I switched after pipenv) to pip-tools for some projects, because Poetry was not able to work properly with some dependencies. Pip-tools has been a dream. It is just a thin layer of tools on top of Pip that separates your 'abstract' requirements (eg: django edit: it also automates updating the release requirements file (within the constraints of the abstract requirements).
Meanwhile, Poetry just announced 1.0: https://python-poetry.org/blog/announcing-poetry-1-0-0.html
- VSCode supports poetry as a second class citizen - Documentation is there, but only in github issues - There is no migration path from pip and pipenv to poetry - I can't do releases via CI because of a poetry bug.
Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem
Just curious, you don't find learning entire languages hard or confusing but suddenly writing 3 commands to set up a venv is too 'messy'?
source?
Earlier quoted context omitted.
probably recording exact dependency versions, based on a loose requirements.txt and when it was built. You may want this because you have a library that you shouldn't be pinning to the third decimal on a sem-ver package, but that you don't want to hiccup in CI due to a dot-release. Or maybe you think a loose file your tooling can read, and a hyper-specific file your builder should read, is a better interface for a pr…
Yes, kind of like that. Except that it doesn't use requirements.txt but rather a file called Pipfile. In there you can also pin version, or leave them unspecified or only partially specified and you can also divide them in dev-packages and normal packages (so it allows for a bit more flexibility than a requirements.txt file).
Earlier quoted context omitted.
> Python packaging in general is such a messy ecosystem Not just messy. It’s probably worst in class. I at least can’t come up with a single worse package-management story which I do know of. Edit: I’m talking about platforms with actual package-management which sucks, not platforms with the absence of package-management all together.
As someone who's been in software development for two the better part of two decades now I would say that's far beyond the truth. Yes it's not great right now and it's not completely clear if I should recommend a new user pip+venv, pipenv, pyenv, poetry or conda and that's a big problem, Python was actually quite early to handle dependencies and packaging in a standardized and structured way. I remember that most of…
Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem
Just curious, you don't find learning entire languages hard or confusing but suddenly writing 3 commands to set up a venv is too 'messy'?
I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools
I recently switched from Poetry (to which I switched after pipenv) to pip-tools for some projects, because Poetry was not able to work properly with some dependencies. Pip-tools has been a dream. It is just a thin layer of tools on top of Pip that separates your 'abstract' requirements (eg: django edit: it also automates updating the release requirements file (within the constraints of the abstract requirements).
The latter works fine for me. What are good reasons to switch to pipenv?