On Thu, Mar 27, 2008 at 10:42 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Mar 27, 2008 at 9:16 AM, Xavier <shiningxc@gmail.com> wrote:
Raymano Garibaldi wrote:
You can not expect people to use an API that has no clear documentation and no stable interface that they can count on. And you can not expect a developer to try to figure out an API by scanning mailing lists, at least not this one. If it takes anyone longer to figure out an API than write their own software, well guess what they're going to do.
Then why don't they write an API with a clear documentation and a stable interface so that everyone could reuse it ? :)
Or, better yet, document the API, or help us document it?
It is clear to us on the list that no one has really latched on to using libalpm. To be honest, I don't blame anyone for this, as the interface seems to have been drawn at a bad level, and calling things like alpm_trans_commit() after 6 other functions and setting flags right just isn't intuitive. So, what does this lead us to? 1. Document the existing interface better. Although it isn't perfect, we aren't going to get frontend clients without documentation. As all of us working on the one client that does use libalpm (pacman) have clearly not felt a need for further documentation, this is really going to have to be spearheaded by someone outside of our current "normal" developers. Anyone want to step up? 2. Frontend developers need to speak up and get ideas on this list. I constantly see rhetoric like the above, where people say the current API is not very good, but they have not done a damn thing to change it. We can't read minds here, and we also aren't going to just change things on our own. So speak up people! If we get some good discussion going, we could really make changes to the API to make it usable. 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Would it? I can tell you this- the pacman 2.9.8 codebase was about half the size of the current monster, and we have a lot of crazy design issues going on. Instead of trying to write a pacman library, why not just implement a friendly frontend, command-line interface, which is a bit more Unix-y? For example, monotone has its "automate" command (I haven't looked at this in some time, so let me know if I am wrong) that is designed to be used by other clients as machine-parseable. git is based around this concept as well- look at all the low level tools like rev-parse, etc. 4. Switch to something like python. I'm resistant to this idea. Although I think scripting languages like this have great benefits, I don't think pacman needs most of them. Having a package manager that always works is important to me, and part of me just thinks a low-level compiled language is the right thing for a system tool. Of the four options above, I have been pushing 1 and/or 2 for a long time. However, I am starting to lean toward option 3. I'd love to hear your thoughts on this. -Dan