Hi Chris Thanks for having a look and offering some feedback!
On Tuesday, 27 October 2020 00:04:03 AEDT Chris Lamb wrote: > Thanks for working on this. I can't think of any additional data that > would be useful right this second. However, I tend to have to use the > library in the 'real world' before I can discover that kind of thing. I completely understand and I'm happy to expand the API once real use tests it out a bit. I might mark it as "experimental" in the documentation just in case real use suggests that some breaking changes are needed too. > > The current code doesn't handle dequoting the environment values and will > > react particularly badly to environment values with newlines in them. > > Do you plan to address this? Would be nice if callsites would be able > to rely on the quoting, as you might imagine. Yes, I think it should do so. I will need to recompletely rewrite that bit of code to accommodate some of the weirder possibilities that are permitted, also checking the code in dpkg that generates the file. > Glancing at the parsed data structures, it would seem like the code is > collapsing duplicate environment keys in the returned value of > get_environment() as well as throw away the original ordering. I would > be okay with this, but we don't do the same for the > installed-build-depends relation. Is this deliberate? It is deliberate, although inconsistent as you note. I'm happy to be told me reasoning is not sound and that different structures would be better: * I chose a dict for the environment as order doesn't matter for the environment and there can't be duplicates in the environment anyway. Python's precedent of using a dict for os.environ felt compelling. We could use an OrderedDict here to explicitly preserve order if that desirable (the dict will accidentally preserve order of course). * I chose a list for the dependencies as that is what is already used for all other package relations within deb822._PkgRelationMixin/deb822.PkgRelation. Ordering of a Depends or Build-Depends may or may not actually matter there as that's down in the weeds of the implementation details of how apt would resolve alternate dependencies. In the case of Installed-Build-Depends, the package list is all-encompassing and should be installable without additional resolution (although I expect that might be simpler to say than do); order shouldn't be an issue there, but I prioritised code reuse and consistent data structures within Deb822 so that existing consumers of the structures from _PkgRelationMixin are usable. The code also only currently consumes these data structures with no provision to edit them via the parsed versions (although the Deb822 super-class would let you edit the raw text and reserialise that to make changes). I've written it on the assumption that dpkg would always be the generator of the file and that python-debian is only providing tools to support analysis. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ [email protected] Debian Developer http://www.debian.org/ [email protected] GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-python-debian-maint
