Activity for ruamel.yaml
-
chirizxc created ticket #570
pass `yaml-test-suite`
-
Karsten Tessarzik created ticket #569
copy.deepcopy loses comments between map key and seq value
-
Eric S. Raymond posted a comment on ticket #568
Somehow I missed an attachment. Here it is.
-
Line wrap should be disabled when YAML was read in rt mode.
-
Sven Stegemann posted a comment on ticket #566
example.yaml contained a typo. Here is the corrected version
-
To reproduce the bug: def test_example(tmp_path: Path): import ruamel.yaml input_file = Path("example.yaml") yaml = ruamel.yaml.YAML() correctly_parsed = yaml.load(open(input_file, "r")) incorrectly_parsed = yaml.load(input_file) output_path_correct = tmp_path / "correct.yaml" output_path_incorrect = tmp_path / "incorrect.yaml" yaml.dump(correctly_parsed, output_path_correct) yaml.dump(incorrectly_parsed, output_path_incorrect) # This assertion fails, because incorrect.yaml contains additional CR...
-
Colin O'Keeffe posted a comment on ticket #567
thanks for the response.
-
Anthon van der Neut modified ticket #567
Support for preserving flow style
-
This is by design as the extra spaces are suprefluous. However the start, end and separator for both collections types are specified as class variables on Emitter as flow_map_start = '{' etc. So you can have any of those "spaced" so the flow styles come out differently (but still all the same way). This request for supprot belongs on StackOverflow where the question has already been answered https://stackoverflow.com/a/76547814/1307905, and it is also mentioned in the ChangeLog
-
Support for preserving flow style
-
Fix #566: RoundTripScanner incorrectly scans comments with CRLF line endings
-
RoundTripScanner incorrectly scans comments with CRLF line endings
-
Adam Dangoor created ticket #565
NEL (U+0085) not escaped during dump, breaks roundtrip
-
`YAML.load` and `YAML.dump` have partially unknown parameter types for pyright
-
Jimmy created ticket #563
TypeError: 'CommentToken' object is not iterable
-
Zach posted a comment on ticket #551
I noticed that this bug shows up in version 0.18.13 of ruamel.yaml - every 0.18.x I tried before doesn't throw this for me . In Sofia's example, it also appears you need default_flow_style = False. However, I have another example that reproduces the issue just by setting typ="rt" (roundtrip): key = "X" * 2 + " " + "X" * 78 yaml = YAML(typ="rt") # safe, unsafe, and base work, rt doesn't yaml.dump({key: None}, stream=stream) stream.seek(0) yaml.load(stream) # ERROR - line wraps without proper complex...
-
Stanislav German-Evtushenko posted a comment on ticket #561
I've created another one with a proper title, feel free to close this one.
-
Line wrapping exceeds requested width with for quoted and folded strings
-
Could somebody change the title and replace "exeeds" with "exceeds", "quioted" by "quoted"? It seems I can't.
-
Could somebody change the title and replace "quioted" by "quoted"? It seems I can't.
-
Line wrapping exeeds requested width with for quioted and folded strings
-
Enrico Scholz created ticket #560
bogus "found character '\t' that cannot start any token"
-
Jeremy Heiner created ticket #559
round-trip fails because value (a seq item) incorrectly renders on same line as key
-
Installation fails when no gcc is available
-
I am not sure how ansible uses ruamel.yaml, but I changed it in 0.19.1, that the dependency on ruamel.yaml.clibz is optional and it is only using built-in pure Python. several users/packages did not follow the instructions to have an up-to-date setuptools installed, which is probably the cause for your issue. I try to enforce that now, so this might work for ansible/your environment. I was not aware of ansible using ruamel.yaml, and certainly not that it didn't pin a version they tested as suggested...
-
Added tag 0.19.1 for changeset 6846cf136e77
-
made requirements optional
-
gcc is not needed to build install ruamel.yaml==0.19.0 what is needed is an up-to-date version of setuptools and wheels, as specified in the README. If that is not done Python installs warns about build_zig, does not follow the build dependencies, and then happely just tries to invoke gcc. The pass in one go would only still try to install ruamel.yaml.clibz (which is the dependency that throws the error when you have the wrong setuptools). You would have to specify --no-deps ruamel.yaml ruamel.yaml.clib...
-
Full name posted a comment on ticket #558
more specific query due to false postives: https://github.com/search?q=ruamel.yaml.clibz+OR+ruamel-yaml-clibz&type=issues&s=created&o=desc I saw the history for the change and it was thoroughly handled, but had some unforeseen usage scenarios. Maybe an easy work around would be a major version bump for the change?
-
0.19 GitHub issues
-
m0ps created ticket #557
Stop of distribution of wheels, has a dramatic impact on some downstream projects
-
Mathieu PARENT created ticket #556
Unable to install with hatch and hatch-pip-compile
-
Peter Uittenbroek created ticket #555
Installation fails when no gcc is available
-
Harmen posted a comment on ticket #513
Hi Anthon, happy new year! I've spent another couple minutes on it, and it seems that this is the full fix. Would be happy to see this finally addressed :) # HG changeset patch # User Harmen Stoppels <me@harmenstoppels.nl> # Date 1767266026 -3600 # Thu Jan 01 12:13:46 2026 +0100 # Node ID 670ee0e7ad049a1d7d97f0cabb8b182eb029c57b # Parent 7938d2acd452c3b5c8f4a1df2dcbc2c7661149ac Fix quadratic complexity and broken referential integrity in deepcopy This commit addresses two critical issues in the deepcopy...
-
Added tag 0.19.0 for changeset 2a6a9c57228d
-
switch to ruamel.yaml.clibz
-
Nathan Goldbaum modified a comment on ticket #554
What is going wrong here is that ruamel.yaml now indicates that for 3.14 the ruamel.yaml.clib should be installed. It used not do that only for up to and including 3.13. Ah, I see! Maybe a simple fix would be to not do that on the free-threaded build: ``` diff -r b90370ceaa6d setup.py --- a/setup.py Wed Dec 17 20:59:34 2025 +0100 +++ b/setup.py Tue Dec 23 12:48:16 2025 -0700 @@ -13,6 +13,7 @@ # # init.py parser import sys +import sysconfig import os import datetime from textwrap import dedent @@...
-
What is going wrong here is that ruamel.yaml now indicates that for 3.14 the ruamel.yaml.clib should be installed. It used not do that only for up to and including 3.13. Ah, I see! Maybe a simple fix would be to not do that on the free-threaded build: ``` diff -r b90370ceaa6d setup.py --- a/setup.py Wed Dec 17 20:59:34 2025 +0100 +++ b/setup.py Tue Dec 23 12:48:16 2025 -0700 @@ -13,6 +13,7 @@ # # init.py parser import sys +import sysconfig import os import datetime from textwrap import dedent @@...
-
What is going wrong here is that ruamel.yaml now indicates that for 3.14 the ruamel.yaml.clib should be installed. It used not do that only for up to and including 3.13. Since ruamel.yaml.clib is not available as .whl for the free threaded version, pip will try to build it from source. So AFAICT nothing to do with the changes for ruamel.yaml.clibz, and that is unlikely to compile for threaded without changes, without me making changes (for Cython). If you just use ruamel.yaml for it preserving format...
-
I can confirm that this is happening. I'm not totally sure what is going wrong though. Perhaps the changes to the build to support zig builds in https://sourceforge.net/p/ruamel-yaml/code/ci/4bd5e2e783003d72327275235a663099474463c2/ broke something on the free-threaded build so that now the clib is an unconditional dependency somehow? https://sourceforge.net/p/ruamel-yaml-clib/tickets/44/ tracks supporting the free-threaded build in the C library. I think the free-threaded build has been broken using...
-
Even Rouault created ticket #554
with Python 3.14.0 free-threading, ruamel.yaml==0.18.17 fails to installs
-
Added tag 0.18.17 for changeset 4bd5e2e78300
-
optionally load _ruamel_yaml_clibz
-
Hi Edward, thanks for the report. This is actually a bug in libyaml, which I inherited in ruamel.yaml.clib, where a fork of the responsible code is located (which gets imported by ruamel.yaml) IIRC there is an open issue there for this already. Best thing to do until that is fixed is to quote the scalar that contains the colon.
-
Edward Knight created ticket #553
C "safe" parser fails to parse {a: b:c}
-
Thanks, that was somehow an incorrect conversion to using F-strings.
-
PR 13 by Mathias Köhler
-
drop 3.8, add !Comment option for test YAML files
-
The error could be more informative, but it is by design that you cannot delete a key that is "merged in". I did not want to faclitate that dict A is merged into B and C, and that deleting a key from B would result in that no longer be available in C. If there would be a way to mask a key in YAML I would implement that. Of course I can do something like that in CoimmentedMap, on deletion, but saving and reloading (revese-roundtrip) would loose that information. An alternative would be copy all the...
-
I would not mind changing a performance issue, but the proposed change breaks a test that has been in existence since 2019: _test/test_issues.py:879: AssertionError ================================================================= short test summary info ================================================================= FAILED _test/test_issues.py::TestIssues::test_issue_295 - assert "A:\n b:\n ... - l33: '5'\n" == "A:\n b:\n ... - l33: '5'\n" ================================================== 1 failed,...
-
Any updates on this? It's a serious performance problem with a trivial fix.
-
Mathias Köhler created merge request #13 on Code
Use repr for obj in RepresenterError instead of str
-
Pip created ticket #552
"KeyError: 1" when deleting key in a map merged elsewhere
-
Sofiia posted a comment on ticket #551
Note: without pure=Truethe bug doesn't reproduce.
-
Implicit key line splitting
-
xdu posted a comment on ticket #550
thank you for the quick response! following your suggestion I debugged locally a bit. the solution is: mv = MergeValue() mv.append(default_metadata) mv.merge_pos = 0 setattr(metadata, ruamel.yaml.comments.merge_attrib, mv) merge_pos is optional and default to None: makes sense. Should it be set to 0 (and keep an internal counter to track the right value) when append is called? I'd also love to know if this implementation is following best practices. would love to get the guidance
-
guidance for referencing anchors (broken after 0.18.15)
-
I cannot run your code as it is incomplete, so what is below is only partly tested. And this is probably better asked on StackOverflow (it worked before, but you are using internals. IMO it is not a bug per se), more people will see this. 1: load the expected output and dump it to make sure the output can (still) be generated from ruamel.yaml import sys import ruamel.yaml yaml_str = """\ default: metadata: &default_metadata foo: bar instances: - name: name0 metadata: <<: *default_metadata - name:...
-
guidance for referencing anchors (broken after 0.18.15)
-
Added tag 0.18.16 for changeset 9a3d0ba0ead2
-
merge PR 12 and improve root literal scalar
-
Fix regression end_mark on CommentToken
-
I merged this, so it will be in the next release. Thanks for the PR. https://sourceforge.net/p/ruamel-yaml/code/ci/51be35b0af4a845f18c62796b002f2d38a49c918/log/?path
-
fix by Taknok
-
Tags not updated on github
-
I have nothing to do with that.
-
https://github.com/commx/ruamel-yaml
-
The only thing I am using github for is driving AppVeyor from https://github.com/ruamel/yaml.clib There are only two other repos for ruamel on github (ordereddict when I still build that for Python2 and a testrepo), so I have no clue what you are looking at, but maybe it is something I abandoned (which is what I tend to do with git). Can you provide a link to the repository?
-
Tags not updated on github
-
Johannes Postler posted a comment on ticket #508
I ran into another issue, where this seems to happen in flow sequences. In such a case, strings with quotation marks are wrapped into the next line and sometimes inserting a whitespace in the process. I have an example at hand, if needed. Thanks to @Hauke for the hint at width.
-
P_g posted a comment on merge request #12
Hi, This is a gentle reminder for this Merge request :)
-
chints posted a comment on ticket #529
This change has caused issue where i am using it. I am using conda environment yaml which has a registry url as list items. This url line has 82 character but while reading, editing and dumping via library is adding a new line after list - This started happening after this update.
-
Alexei Znamensky posted a comment on ticket #546
Hi there, I can confirm that 0.18.15 is passing the tests (in the andebox project).
-
d.schmid posted a comment on ticket #526
This seems to be a windows-specifc bug. I'm able to reproduce this in 0.18.15 on windows but not on linux. maybe something about line-endings.
-
Peter L Jones posted a comment on ticket #526
Unable to reproduce this in 0.18.15.
-
roundtrip of aliased sequence value for merge key shifts aliases to mapping(s)
-
fixed in 0.18.15
-
Added tag 0.18.15 for changeset d3d281cdfa9d
-
fix issue with aliased sequence as merge value
-
fix issue 548 with aliased merge value
-
"Unintended YAML Aliases (&id001, *dev-service) and Duplication When Modifying YAML with ignore_aliases Settings"
-
without an example file, I cannot work on this.
-
roundtrip of aliased sequence value for merge key shifts aliases to mapping(s)
-
Gernot Salzer posted a comment on ticket #528
Thanks a lot for the pointer to StackOverflow. Your answer to How to change one of the attribute reference to anchor in ruamel.yaml from 2020 seems to answer also my question. Still have to try it out, but the given example is exactly my case.
-
There might be a stackoverflow post on that, I am not sure. But the since you can round-trip merge-keys without losing them in ruamel.yaml follow the usual recommendation: 1) check that the round-trip works, 2) inspect the intermediate result. If you look at CommentedMapand how it is constructed/filled in constructor.py:RoundTripConstructor.flatten_mapping. (see how the local merge_map_list is constructed. If the yaml parser can construct it from YAML, you can do the same from just Python. The only...
-
There is another issue with accepting multiple mereg keys. Given the way merge keys are defined (insert keys from the merge key value dict(s)), and because the key ordering in mapping is unordered in YAML, there is no deterministic way to get a result from two merges ( the sequence of dicts that can be a value for a merge is, of course ordered).
-
Why I actually came here: I'm trying to find out how to construct a mapping, in Python that contains something like <<: *A or <<: [*A, *B]. So not reading the structure and updating it, but constructing it from scratch. Can you give any pointer to an example (like a test case) or other reference?
-
You are right, I was misled by the fact that several YAML checkers and YAML-JSON converters accept multiple << keys as "Valid YAML" and merge the referenced dicts successively. Apparently the correct form to specify it is <<: [*A. *B]
-
Please update your claim with a link to official documentation where it says it is an operator.
-
As I understand it, the issue seems to be that data = yaml.load(""" --- - &A a: 1 b: 2 - &B c: 3 d: 4 - <<: *A <<: *B """) gives an error "duplicate key", apparently because of << occurring twice. I understand that ruamel.yaml may not support it, but this is valid yaml, and << is not a normal key, but an operator.
-
Fix regression end_mark on CommentToken
-
Michael D Michaels posted a comment on ticket #547
Thanks, Actually I may have it working now. This makes it easier for companies to approve your library in their code.
-
eanble OpenHub to analyze source code
-
I don't know who put that there. If you can just delete the entry, thank you.
-
eanble OpenHub to analyze source code
-
Pinky posted a comment on ticket #516
Sorry, this is expected actually, the correct indent call is the one mentioned above and it works as expected
-
Another example: - c: cv d: e yaml.indent(mapping=2, sequence=2, offset=2) results in - c: cv d: e
-
pypi doesn't allow me to upload a package named ruamel
-
mshafer-ni posted a comment on ticket #536
(also, any way I can help?, I could potentially do that and add you as a maintainer...)
-
In theory, create an upload a package with an empty init.py in it (called ruamel), have the README.md for that say "this is a namespace package". (albeit, I have not done this before myself)
1 >
