Shawn Walker wrote: > Michal Pryc wrote: >> Brock Pytlik wrote: >>> Michal Pryc wrote: >>>> Hello, >>>> I have made some changes to support BE Management: >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=3201 >>>> >>>> The webrev is at: >>>> http://cr.opensolaris.org/~migi/10_09_be_management_3201_v1/ >>> I know the interface to libbe has changed (or changes in 97). Please >>> take a look at the change Tim Knitter put back (501:9467b61d5b40) >>> and do >>> something similar every place you use be.beList. We need this to be >>> compatible both with the new code and the old code so we can >>> continue to >>> back-publish. >>> >>> beadm.py line 163 is where be.beList is being used. >>> >>> It's also probably worth your time to talk to the people writing libbe >>> to find what changes they might have planned for their API, or to at >>> least let them know that you're directly dependent on them. Ethan Quach >>> is the person who've I've talked with about libbe before. >>> >>> beadm.py: You might consider using our misc.py bytes_to_str method >>> instead of rolling your own in __convert_size_of_be_to_string(self, >>> be_size). I'm guessing that what we have should be sufficient, or >>> can be >>> made to do what you need it to do. >> >> Good to know. I didn't wanted to depend on more code from IPS, since >> this would introduce risk if the misc.py bytes_to_str would be >> changed or renamed. What do you think? > > If it gets renamed by us, it's our responsibility to fix it. If it > gets changed, that's on purpose. Either way, using that function will > be good since it will ensure that the gui and cli represent sizes of > "things" the same way. >
I disagree with this answer, at least in the long term. This is exactly how we got into this problem in the first, and why we're creating an API in the first place. Now, if we want to confer onto misc.py special API status such that every change made in that file has to be vetted against everything, then I'm fine with that answer. My impression is that misc is more or less a dumping ground for things we don't have better places for. Six months or a year from now, are we likely to remember that this one function of misc.py has been given special status? This answer puts us in the position of having to test every change against the GUI manually (until automatic testing comes along) because any piece of our code could be used by the GUI or each of us needs to become familiar with the GUI and track its changes. (The CLI suffers from this same problem but is easier to deal with because we have automated testing and we all know the code base letting us have a reasonable idea of what our impact will be.) If we think it's important for the GUI and the CLI to display byte information in the same pattern, then that becomes part of the conceptual API/standards. If the GUI makes calls into misc.py, then that function becomes part of the implementation API. Neither of these imply that the function has to move into api.py, but it does confer a status on that function that isn't given, generally, to most of our functions. That being said, if this is a short term solution, I don't really care. Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
