Merge lp:~brian-murray/cupstream2distro/bug-1530870 into lp:cupstream2distro
Proposed by
Brian Murray
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 1352 | ||||
Proposed branch: | lp:~brian-murray/cupstream2distro/bug-1530870 | ||||
Merge into: | lp:cupstream2distro | ||||
Diff against target: |
37 lines (+6/-5) 2 files modified
cupstream2distro/silomanager.py (+4/-3) tests/unit/test_silomanager.py (+2/-2) |
||||
To merge this branch: | bzr merge lp:~brian-murray/cupstream2distro/bug-1530870 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Bruce Park (community) | Approve | ||
Review via email: mp+284805@code.launchpad.net |
To post a comment you must log in.
Clever job getting the series from the filename, I'll need to think about how stable that'll be (the file path has changed a few times over the years).
There's an unrelated issue that affects this part of the code as well, let me know if you'd like to tackle it within the same branch or if it makes more sense to do it as a separate branch.
The thing is that these files you're reading don't even need to be created in the first place. It used to be that these files would be created at one point, preserved on the server, and then read at a different point, but the architecture of the system has shifted a bit and we currently do a silly sort of thing where one part of the code writes these files, another part of the code immediately reads them, and then when the job is done running it all gets deleted. So it should be possible to just set a value in an instance attribute somewhere rather than even writing/reading to disk at all.
Take a look here:
http:// bazaar. launchpad. net/+branch/ cupstream2distr o/view/ head:/cupstream 2distro/ archive. py#L217
That's where the file is written, in Archive. archive_ pocket( ). Instead of calling set_file (and indeed if you drop set_file I think set_file can be entirely deleted as this is the last remaining user of the method), just set an instance attribute, and then in SiloManager. published_ versions you should be able to iterate over all the build objects and their 'published' attribute. Although SiloManager probably doesn't have a direct reference from one to the other so you might need some poking to connect the dots there.