Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
My personal opinion is that making your own custom config file format sends you immediately to some ring of programming hell. Let's call it YAYAML :)
Anyway, since we've got it and I'm sure someone will tell me that we should have it and we can't use YAML or XML, I think we do need a generator.
Here is a first pass at what is probably a rather piss poor version of one.
Comment | File | Size | Author |
---|---|---|---|
#19 | 537332.patch | 2.72 KB | RobLoach |
#18 | common-provide_drupal_build_info_file-537332-18.patch | 3.11 KB | kscheirer |
#16 | diff.patch | 3.65 KB | Bronsa |
#13 | test.patch | 2.15 KB | Bronsa |
#10 | common.inc_.patch | 1.37 KB | Bronsa |
Comments
Comment #1
JacobSingh CreditAttribution: JacobSingh commentedComment #3
mikey_p CreditAttribution: mikey_p commentedJust out of curiosity, do you have a potential use case for this?
Comment #4
JacobSingh CreditAttribution: JacobSingh commentedYeah, trying to make a packaging script which will modify info files based on some user customizations.
It could be in contrib, but if you make up YAYAML, I think it should have a parser and a printer, and so I think it should be in core. Really though, I think we should switch to YAML and use a 3rd party parser / generator.
-J
Comment #5
mikey_p CreditAttribution: mikey_p commentedWell, okay, I've dug out the original issue for drupal_parse_info_file(): #132018: Add .info files to themes (and improve/clean up the theme system). The discussion regarding YAML starts here.
While it's not fun to read through that issue, there was less opposition to YAML there than I remembered. The main arguments against YAML seemed to be:
I've thought about this before, and done some basic work with YAML. The most prominent YAML parser is spyc and it comes in at almost 1000 lines and 28KB, so argument 1 has some validity. Also, there are a few issues with spyc, for example, it is not currently NOTICE free. It is also used by: symfony (1.0 branch), livepipe, guesswork, andromeda, akelos, and probus.
Argument 2 is so subjective that discussing it would most likely bring no value. (XML is perhaps more debatable, but still...) Without some testing, I don't know how we could answer this conclusively.
#3 ? It would be great to see Dries weigh in before starting?
One of the biggest issues I see, is if the above concerns are address/considered acceptable, do we roll our own YAML parser, based on spyc, write our own from scratch, or just include spyc as is? Overall I'd have to say, that while the library is large, I'd be against modifying it, or including some form of YAML-lite. It's tempting to roll our own, but our time could perhaps be better spent fixing the small issues in it, and then concentrating on other performance issues? (Unless this happens to be a major performance issue).
Comment #6
JacobSingh CreditAttribution: JacobSingh commentedWow, nice research!
I don't really want to get into the argument of inventing our own vs using an existing standard / toolkit because I guess it's already done, just giving my 2c that unless it's a massive performance difference, using an existing tool wins in my book.
Comment #7
chx CreditAttribution: chx commentedDries http://drupal.org/node/132018#comment-534330 argument was ". It's not consistent with the module .info files, which I think is important." There was no other real argument against YAML just saying "it's a mess" when it's not. walkah and I were in favor and dww was at least not against.
Comment #8
Bronsa CreditAttribution: Bronsa commentedComment #10
Bronsa CreditAttribution: Bronsa commentedsorry, the previous patch had been created using diff, this should be ok, i created it using cvs -up
Comment #11
cwgordon7 CreditAttribution: cwgordon7 commentedComment #12
cwgordon7 CreditAttribution: cwgordon7 commentedThis is going to need accompanying unit test files. Please read the documentation, or ask on IRC (#drupal-gci or #drupal-contribute) if you need help. Thanks!
Comment #13
Bronsa CreditAttribution: Bronsa commentedHere it is the unit test
Comment #15
cwgordon7 CreditAttribution: cwgordon7 commentedThis looks good, can you please just roll both changes into one patch, made relative to the root Drupal directory? See http://drupal.org/patch/create if you need help creating patches. Once the patch is properly formatted, we can run it through our automated test system and make sure it passes tests. Thanks!
Comment #16
Bronsa CreditAttribution: Bronsa commentedOk, here it is
Comment #17
webchickComment #18
kscheirerrerolled for HEAD.
Comment #19
RobLoachYAML is what we're using for configs, but I have a hunch that we'll want this this compatibility layer for our .info files too. We might want to switch our .info files to YAML at some point, and this wrapper layer is the way to go for that.
Comment #20
Jeff Burnz CreditAttribution: Jeff Burnz commented#19: 537332.patch queued for re-testing.
Comment #22
Crell CreditAttribution: Crell commentedI'm pretty sure we can close this issue, since we don't use info files anymore.