As someone who continually has to deal with issues that only happen intermittently and seemingly with the same inputs having different behavior, this would 100% annoy the heck out of me. I can't believe that a fellow developer would think that this is an acceptable behavior to add, ESPECIALLY in a CI environment.
Tell me how a creator isn't using their own tools, without telling me they're not using their own tools. At least not in a CI environment in any meaningful capacity. ¯\_(ツ)_/¯
A 5% chance to randomly fail in CI is ridiculous, as is the overnight deprecation and removal. I was looking into using poetry but your thoughts have definitely made me reconsider.
That random in CI stuff is... something. Shows that the people behind this project haven't got a good understanding of how people build stuff in the wild, which is indeed disconcerting
I've never seen someone do something like before. And it seems like it was a very poor decision to do so. Why would I ever use a project where it's the intention to randomly fail? Never. I would never use it and would never have any confidence in using it.
@@AceofSpades5757 as an open source maintainer myself I don't like to resort to that kind of language and I'm sure that their motives were good, but it does raise concerns for the level of proficiency to be expected from the project
@@OrCarmi That's fair. I will update my wording to avoid insulting anyone. I meant it to convey how I felt on the matter, but that was a bit harsh on my part.
I'm still a big fan of Poetry and will keep using it; However, your arguments here are very good, and I actually agree with them - it's bad to automatically update deps within major versions by default (because it's quite common to reach breaking changes between different minor versions), and it's SUPER BAD to introduce random breakages in CI builds just to "force" people to stop using some deprecated feature. Thanks for the video, you got a new subscriber 🙂
As someone who's dabbled in Poetry and really liked it, I found your video so informative that it got you my subscription. I'm really looking forward to watching some of your other videos!
I had not heard of pip-tools but a brief look at it makes me think it could solve some problems I've had with dependency management. Thanks for introducing me to it!
Thanks for doing this one, now I can send others asking about poetry to your video. Much easier than having endless debates about why some feel the need for Vogon poetry. There are also other reasons, but if I remember well they would fit in the same category as your example regarding making deliberate decisions that disconsider the user-base. That kind of aggressiveness around deprecations I unacceptable, at least in my view. I was even upset about how aggressive was pip around reporting that is outdated, but what poetry did took it a new level.
It's a very WTF decision. I moved away from poetry as well. now I need to convince work to do the same, but it'll be... hard given we migrated into poetry not that long ago...
The greatest value for me in poetry is how it helps manage and hence democratize the use of pyproject.toml. This really helped set our team on a journey to sane packaging and dependency management. The randomness in CI is wild though and we've definitely ran into weird stuff with poetry also the change in how hashes are handled before 1.2 compared to after which also broke our CI.
Adding randomness is pure evil. Must have caused so much head-scratching and aggravation to people who were on this version. Edit: thanks about the pip-tools suggestion :)
Wow, ty for sharing this! Not that long ago we've just dealt with flask lib, that had something similar where they simply changed the default behavior, although wasn't even intended to be removed at the end. I went crazy about it. You should do another video about how flask.request.json changed from version ~1.X -> 2.2.X it's default behav.
I thought the video was clickbait and you were actually going to like it in the end but wow ok. I just started looking at poetry this morning because setuptools which i build pypi wheels in is so hard to manage. So what is the best practice to make pypi projects?
It is best practice to make changes to the interface just in major version changes, so it makes absolut sense to default to be compatible just to the same major version of a dependency
Great technical details. Can you please do a review of uv as an alternative to pip and virtualenv as both a Python package manager and project manager? Thanks in advance.
As someone whose primary language is not Python, I found poetry makes project maintenance a lot easier. Having to manually manage venv and fiddle with requirements.txt just to bump minor versions for security patches is too much overhead.
Poetry is still pretty good for mono-repo projects where you have 100 independent venvs; v1.2 has a lot of breaking changes; I agree they had to communicate better, but I guess poetry plays a big role in the future; especially in ML/DS world where side projects like `poetry-kernel` makes the venv management way easier
There were some serious red flags, in the poetry issues page, and this just cements my decision to undo a weeks worth of work in converting my projects to poetry. I hate python.
Hi, I have a small question. My project has quite too many dependencies and of course I would want to decrease the number of dependencies but right now every time a package I am using is getting upgraded and it breaks my Code the I need to lock its version. What would you advise me to do? Lock all versions of outside packages so I my code wont have problems so often? Or is it better to always upgrade the external packages? Thanks!
Nice video, as for me poetry is slow (its really visible on CI and also locally when versions of some libs are changed) and complicated, now I'm switching projects to uv. Seems like uv is the best tool for now.
pdm used to do really really strange and scary ways of putting things on sys.path -- though they recently switched to just being a virtualenv creator and dependency manager which at that point what are you gaining over just using the vanilla tools (ok maybe a slightly centralized interface? but also a whole other place for bugs) -- nothing imo so it sits firmly in yagni territory
Going from completely fine to breaking due to safety reasons is not that bad, but adding 5% chance error is comic and overthetop! Hahaha that is mess up!! Hahah
Thanks Anthony for all of your great videos. As a new Python coder, I find Poetry is easier than Venv or pip-tools. Poetry documentation is easier to follow. Maybe when I am more advance user, things will change.
I've dabbled in python over the years despite not being a python dev, and it seems to me that the whole idea of virtual environments is an artificially created necessity due to the limitations of the pip package manager. I believe poetry does not come with those limitations, so just like alot of other package managers like npm, maven or the Go package manager, I believe I can use poetry on its own to manage everything related to packages and versions. So yeah, maybe in this case it is a good step forward to move away from the current python package management zeitgeist.
basically a directory that looks like /usr (and is enabled by "prefix"ing PATH). I believe named after the common argument `--prefix` to `./configure`)
@@NostraDavid2 TLDR A developed lack of confidence over the years. Too bad because I really liked the interface. Due to its ergonomics, I used it for most of my projects. Over the years it's had problem after problem after problem. Serious performance issues and difficult to diagnose bugs, which I usually thought was the code base but just turned out to be pipenv, have forced me to purge it from all my projects. P.S. For my next project, I'm going to try out pip-tools. Sounds like it would be a great complement to virtualenv.
I can think of some shenanigans based on the implementation 😂 since they are using the global implicit random instance, what if I set random.seed to something that would never cause a brownout failure.
I actually find the 5% break interesting. After having to track down countless teams tha ignore updates, I would say shaking people with a broken build is interesting. If there is no way to bypass this without upgrading and upgrading is breaking things, them.bad implementation. But lets be honest who scans logs on successful builds?
I certainly agree that on deprecation, there should be a grace period to allow people to migrate, and this doesn't appear to allow for that. Regarding the 5% failure, I kinda get where they were coming from, the likely hood of people looking at deprecation warnings in succeeding CI jobs is pretty slim, so they wanted to make a little noise, to draw people's attention to the fact that some thing has been deprecated, but not cause an outright failure suggesting code breakage. That being said, I can certainly see why that would irk some one.
Nice video, I am for giving people their choices. As a developer, I want a dependency manager that is opinionated and does not stray too far from selected apis. For me pip freeze bundles dependencies of dependencies, ignores missing/broken dependencies. Chances I no longer want to use that library as it is not well maintained or old. For projects like ansible-lint to deliberately break poetry support 100% of the time is childish.
I think this naturally calls for a video on piptools now
As someone who continually has to deal with issues that only happen intermittently and seemingly with the same inputs having different behavior, this would 100% annoy the heck out of me. I can't believe that a fellow developer would think that this is an acceptable behavior to add, ESPECIALLY in a CI environment.
Tell me how a creator isn't using their own tools, without telling me they're not using their own tools. At least not in a CI environment in any meaningful capacity. ¯\_(ツ)_/¯
A 5% chance to randomly fail in CI is ridiculous, as is the overnight deprecation and removal. I was looking into using poetry but your thoughts have definitely made me reconsider.
That random in CI stuff is... something. Shows that the people behind this project haven't got a good understanding of how people build stuff in the wild, which is indeed disconcerting
I've never seen someone do something like before. And it seems like it was a very poor decision to do so. Why would I ever use a project where it's the intention to randomly fail? Never. I would never use it and would never have any confidence in using it.
@@AceofSpades5757 as an open source maintainer myself I don't like to resort to that kind of language and I'm sure that their motives were good, but it does raise concerns for the level of proficiency to be expected from the project
@@OrCarmi That's fair. I will update my wording to avoid insulting anyone. I meant it to convey how I felt on the matter, but that was a bit harsh on my part.
I'm still a big fan of Poetry and will keep using it; However, your arguments here are very good, and I actually agree with them - it's bad to automatically update deps within major versions by default (because it's quite common to reach breaking changes between different minor versions), and it's SUPER BAD to introduce random breakages in CI builds just to "force" people to stop using some deprecated feature.
Thanks for the video, you got a new subscriber 🙂
As someone who's dabbled in Poetry and really liked it, I found your video so informative that it got you my subscription. I'm really looking forward to watching some of your other videos!
Great video Anthony, thanks! It would be nice to watch a video about pip-tools
+1
I had not heard of pip-tools but a brief look at it makes me think it could solve some problems I've had with dependency management. Thanks for introducing me to it!
Interesting way to tell users that it’s time to fork or find something else
BROWNOUT_CHANCE = 5
GET_RID_OF_POETRY_CHANCE = 95
couldn't agree with you more
Thanks for doing this one, now I can send others asking about poetry to your video. Much easier than having endless debates about why some feel the need for Vogon poetry. There are also other reasons, but if I remember well they would fit in the same category as your example regarding making deliberate decisions that disconsider the user-base. That kind of aggressiveness around deprecations I unacceptable, at least in my view. I was even upset about how aggressive was pip around reporting that is outdated, but what poetry did took it a new level.
It's a very WTF decision. I moved away from poetry as well. now I need to convince work to do the same, but it'll be... hard given we migrated into poetry not that long ago...
Pip-tools is great
@@lonterel4704 I migrated to pip tools indeed
I'm in the same boat :(
I typically watch videos at 2x speed, but this time I'm watching at 0.5x speed.
.5x speed but only 5% of the time?
The greatest value for me in poetry is how it helps manage and hence democratize the use of pyproject.toml. This really helped set our team on a journey to sane packaging and dependency management.
The randomness in CI is wild though and we've definitely ran into weird stuff with poetry also the change in how hashes are handled before 1.2 compared to after which also broke our CI.
I'm a big proponent of pyproject.toml as well. if someone isn't happy about using Poetry there's alternatives available like Flit.
Ironically Poetry does not comply with PEP-621
wow, best breakdown I've seen thus far on actual technical reasons as to why not to use poetry. Great job! Loving your vids
Did you need to install poetry inside a venv? Isn't it designed to be installed at system level, and then it effectively creates a venv?
I install nothing globally th-cam.com/video/O390_abzo08/w-d-xo.html
did you click the link?
Adding randomness is pure evil. Must have caused so much head-scratching and aggravation to people who were on this version.
Edit: thanks about the pip-tools suggestion :)
Wow, ty for sharing this! Not that long ago we've just dealt with flask lib, that had something similar where they simply changed the default behavior, although wasn't even intended to be removed at the end. I went crazy about it. You should do another video about how flask.request.json changed from version ~1.X -> 2.2.X it's default behav.
to be fair, flask had been warning about that change for a very long time
I thought the video was clickbait and you were actually going to like it in the end but wow ok. I just started looking at poetry this morning because setuptools which i build pypi wheels in is so hard to manage. So what is the best practice to make pypi projects?
I don't do click bait
@@anthonywritescode you in fact do clickbait, but actually make the video about what people clicked for, so it's good clickbait
It is best practice to make changes to the interface just in major version changes, so it makes absolut sense to default to be compatible just to the same major version of a dependency
that mentality is harmful. yes breaking changes _may_ occur but they're unlikely to affect the core use of a library and without notice
Ekk. I did use setup-py-upgrade as part of converting 10's of poetry pyproject.toml's to setup.cfg's so thanks for making that.
I thought the "percent change to randomly fail" was just a hyperbole for the thumbnail. But they actually did it for real... wtf
Great technical details. Can you please do a review of uv as an alternative to pip and virtualenv as both a Python package manager and project manager? Thanks in advance.
I probably will not given my other video about astral
As someone whose primary language is not Python, I found poetry makes project maintenance a lot easier. Having to manually manage venv and fiddle with requirements.txt just to bump minor versions for security patches is too much overhead.
Sorry this is off topic, it's my first time seeing a video of yours. I just gotta know, what keyboard is that?
it's the kinesis freestyle pro -- here's my review of it and more details: th-cam.com/video/DZgCUWf9DZM/w-d-xo.html
Thanks!
Poetry is still pretty good for mono-repo projects where you have 100 independent venvs; v1.2 has a lot of breaking changes; I agree they had to communicate better, but I guess poetry plays a big role in the future; especially in ML/DS world where side projects like `poetry-kernel` makes the venv management way easier
Use pants for monorepo
my point is "venv management isn't hard and poetry somehow makes it more complicated"
For ML/DS we’re stuck with conda. Mostly for the package repository.
There were some serious red flags, in the poetry issues page, and this just cements my decision to undo a weeks worth of work in converting my projects to poetry. I hate python.
Anthony, what's up with the thumbnails😚? Looks good though 😎
I'd love to hear your opinion on PDM. It's PEP standards friendly and it's dependency resolver is much more robust.
a few other comments have asked below vvv
After watching this video, another video about pip-tools is must right?
something to manage tons of packages, cannot be a tons of packages itself
i use git submodule to 'install' a package manage module written by myself based on venv. it has no third party dependencies except stdlib
Easy ("temp") fix for poetry: pin the version to something pre-1.2.0
Hi, I have a small question. My project has quite too many dependencies and of course I would want to decrease the number of dependencies but right now every time a package I am using is getting upgraded and it breaks my Code the I need to lock its version. What would you advise me to do? Lock all versions of outside packages so I my code wont have problems so often? Or is it better to always upgrade the external packages?
Thanks!
I tend to:
- reduce deps wherever possible
- lock everything in applications
- be proactive about upgrading
I'll actually have a video coming out either later this week or next week which goes into further details about my strategy here
Thank you very much! Much appreciated🙏
What about pipenv? Have you tried it, is the experience any different?
some of the same reasons as poetry (slow, yagni) but also I won't use it due to the original author
they did... what......
Why do you use virtualenv and not venv? habbit, or actual reasons?
Anthony has made a video about it: th-cam.com/video/MGTX5qI2Jts/w-d-xo.html
th-cam.com/video/MGTX5qI2Jts/w-d-xo.html
Nice video, as for me poetry is slow (its really visible on CI and also locally when versions of some libs are changed) and complicated, now I'm switching projects to uv. Seems like uv is the best tool for now.
I'd be interested in your take on PDM as I swapped from poetry to PDM ages ago and still use it
pdm used to do really really strange and scary ways of putting things on sys.path -- though they recently switched to just being a virtualenv creator and dependency manager which at that point what are you gaining over just using the vanilla tools (ok maybe a slightly centralized interface? but also a whole other place for bugs) -- nothing imo so it sits firmly in yagni territory
Going from completely fine to breaking due to safety reasons is not that bad, but adding 5% chance error is comic and overthetop! Hahaha that is mess up!! Hahah
Thank you for the detailed video, not going to use poetry.
Thanks Anthony for all of your great videos. As a new Python coder, I find Poetry is easier than Venv or pip-tools. Poetry documentation is easier to follow. Maybe when I am more advance user, things will change.
What about PDM?
I've dabbled in python over the years despite not being a python dev, and it seems to me that the whole idea of virtual environments is an artificially created necessity due to the limitations of the pip package manager. I believe poetry does not come with those limitations, so just like alot of other package managers like npm, maven or the Go package manager, I believe I can use poetry on its own to manage everything related to packages and versions.
So yeah, maybe in this case it is a good step forward to move away from the current python package management zeitgeist.
they are just first class prefix environments but made convenient. not due to any sort of limitations
and poetry uses virtual environments so your comment makes you look ignorant :)
@@anthonywritescode ah in that case yeah i was being ignorant.
@@anthonywritescode but i do not quite understand what you mean by “first class prefix environments”
basically a directory that looks like /usr (and is enabled by "prefix"ing PATH). I believe named after the common argument `--prefix` to `./configure`)
What happened to easy install?
true!
what about pipenv?
I love/hate poetry. It is great until it is suddenly terrible.
I've heard a lot of good things about poetry, but have had a stack of problems when using it that made me avoid it for all my projects.
Tbf, it's closest relative, pipenv, is blocklisted for all my projects and gets gutted for any older projects that I spot.
@@AceofSpades5757 How so? I never used pipenv, so I won't mind the information :)
@@NostraDavid2 TLDR A developed lack of confidence over the years. Too bad because I really liked the interface.
Due to its ergonomics, I used it for most of my projects. Over the years it's had problem after problem after problem. Serious performance issues and difficult to diagnose bugs, which I usually thought was the code base but just turned out to be pipenv, have forced me to purge it from all my projects.
P.S. For my next project, I'm going to try out pip-tools. Sounds like it would be a great complement to virtualenv.
I can think of some shenanigans based on the implementation 😂
since they are using the global implicit random instance, what if I set random.seed to something that would never cause a brownout failure.
WTF is going on with 5 percent chance of throwing an error?!?
Did they ever justify or provided their thought process?
I agree, but my pro-poetry colleague won the argument, considering hashing and sources URI
you can do that directly with requirements.txt fwiw
I don't have any issues with that tbh
after 1year, do you think this is still true please ?
if I didn't I would have issued a correction and taken down the video
Wait, did I understand correctly that this was only ever added to an alpha? This appears to make this a non-issue to me
it was added in an alpha and then released to everyone because it was through a website and not through normal mechanisms
@@anthonywritescode That actually seems worse somehow... Oh gosh...
Seems that the problem is the requests library, not poetry
did you watch the video? this has nothing to do with requests?
Hi Antony, after one year of your video, still thinking you will not use poetry?
have the reasons in the video changed?
does "never" not include 2024?
What does "poetry"? i can't tell by the name at all. and all "beautiful soup"?
I actually find the 5% break interesting. After having to track down countless teams tha ignore updates, I would say shaking people with a broken build is interesting. If there is no way to bypass this without upgrading and upgrading is breaking things, them.bad implementation. But lets be honest who scans logs on successful builds?
I reckon most people would notice a warning when developing. even still there's no world that a random failure is an acceptable practice
What about pipenv?
maybe if I wanted to make every operation slower for no reason. I also won't use any software written by the original author on principle
I feel your pain!
PDM is the way
I certainly agree that on deprecation, there should be a grace period to allow people to migrate, and this doesn't appear to allow for that.
Regarding the 5% failure, I kinda get where they were coming from, the likely hood of people looking at deprecation warnings in succeeding CI jobs is pretty slim, so they wanted to make a little noise, to draw people's attention to the fact that some thing has been deprecated, but not cause an outright failure suggesting code breakage.
That being said, I can certainly see why that would irk some one.
but it did cause an outright failure, at 5%
Nice video, I am for giving people their choices. As a developer, I want a dependency manager that is opinionated and does not stray too far from selected apis. For me pip freeze bundles dependencies of dependencies, ignores missing/broken dependencies. Chances I no longer want to use that library as it is not well maintained or old. For projects like ansible-lint to deliberately break poetry support 100% of the time is childish.
? if poetry is that fragile and the official packaging tool can handle it surely poetry is the problem
5% chance to fail XDD tf is this Pokemon??
how disgusting...
pipenv vs poetry makes my head hurt
poetry is xxxx trash for sure dont run it so many bug