-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase off ruamel? - many new valuable features #46
Comments
There are presently too many users of PyYAML that could break if we were to just wantonly pull in ruamel.yaml. If folks want to help pyyaml by contributing fixes and YAML 1.2 compatibility that's more than welcome. Rebasing off a completely separate project (regardless of origin) carries too much risk in my opinion. We would need far better testing before we could be certain that the updates wouldn't break downstream consumers of PyYAML which have been relying on the stability of releases for the last few years. |
On the other hand, PyYAML has been practically dead for the last several years so there shouldn't be urgent need for backwards-compatible update. That is to say, that if you bumped version into 4.x, those upgrading should understand that things have changed and they must pay special attention if they wish to upgrade, as usual. Related ticket in Bitbucket: https://bitbucket.org/ruamel/yaml/issues/81/merge-back-into-pyyaml The author wrote there:
He also states:
I don't personally, as a user of the library, care too much about the name. I do however, humbly acknowledge and appreciate the work authors have put into it the projects (both @xitology and @AvdN, plus whoever has contributed). It would just feel a bit weird to re-implement the code already existing in So, if PyYAML is dead and |
@tuukkamustonen PyYAML isn't dead. We're also not reckless.
Yes, except in most cases people don't take care with their dependencies. I'm also a requests maintainer. When requests bumped to 1.0 (and then to 2.0) we documented our breaking changes and still were treated as if we had done some world ending thing. Now, PyYAML isn't downloaded nearly as much as requests, but I'm not keen to make the same mistakes. Many projects use PyYAML in their requirements without a pin or an upper cap (e.g., We don't want to duplicate the work that went into ruamel.yaml but it looks as though Anthon is frustrated with the author for not being responsive and further frustrated with the maintainers for moving the project to GitHub. I have been focusing more on libyaml right now, but pyyaml will soon be on my list. I plan to migrate the open pull requests on bitbucket (which include Anthon's https://bitbucket.org/xi/pyyaml/pull-requests/6/merge-of-python2-and-python3-codebases/diff) and review them as they are. So in all likelihood we'll end up converging on the same code-base, but it needs to be reviewed carefully and tested appropriately to ensure we continue to provide the stability to our users that they expect. |
It's silly to not do this just because you may hurt folks who have bad practices with regard to dependency tracking. |
It seems like this would be a good idea because pyyaml has the most history and ruamel.yaml is more up-to-date (or so they say). Status report? |
We actually would like to make a PyYAML release soon. I just started to try and help out here, but I don't have much experience with Python so far, so what I can do is limited. As far as I know ruamel and PyYAML have different implementations, but that's about all I know. |
I could take on a small task. |
ruamel.yamel is a fork off PyYaml which has been much more active in recent years. According to the author it passes all PyYaml tests and so it should be more or less backwards compatible.
At the same time it has many new features and code improvements such as
It would be really useful if these features could be available to all the users of PyYAML. Currently there are many more changes in ruamel.yaml than in PyYAML. Also I believe it already has some of the fixes. This means it would be easiest to rebase off ruamel.yaml and then port all of the new work on PyYAML. I'd like to propose that.
Probably easiest would be to just import the ruamel.yaml code into the current repo, but there could be other proposals such as starting to use the existing ruamel repository (unfortunately it's a mercurial repo so wouldn't be fully compatible with github).
Any comments on this? Reasons not to?
The text was updated successfully, but these errors were encountered: