[pacman-dev] Libalpm direction and usage by others
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
3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Yes, I think so.;-)
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. Well, I don't think we can easily compare the current codebase with 2.9.8. There were _dozens_ of bugs in 2.9.8, after 3.1.3 release we got no "real" bugreport in FR. I think library is better than some server<->client stuff, because now we can easily share internal things with the front-end (for example: pkgcache) without interchanging tons of data. So my vote: keep libalpm library.
Bye
On Thu, Mar 27, 2008 at 12:33:18PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
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.
there are other good examples, like git, darcs or mplayer's slave mode, where the interface is script-friendly, so (almost) nobody claims for a library.
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.
exactly. you probably heard of the poor gentoo guys who broke their python, losing their package manager as well :P
Miklos Vajna wrote:
On Thu, Mar 27, 2008 at 12:33:18PM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
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.
there are other good examples, like git, darcs or mplayer's slave mode, where the interface is script-friendly, so (almost) nobody claims for a library.
Well, maybe if pacman was really designed with this in mind, I would find it less ugly indeed.
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.
exactly. you probably heard of the poor gentoo guys who broke their python, losing their package manager as well :P
That's true, but hmm.. Even though I don't know python well, it seems many programmers like it and are efficient with it, so it would probably be more practical from that point of view.
On Thu, Mar 27, 2008 at 11:11:19PM +0100, Xavier <shiningxc@gmail.com> wrote:
That's true, but hmm.. Even though I don't know python well, it seems many programmers like it and are efficient with it, so it would probably be more practical from that point of view.
don't get me wrong, i love python. but i would never write pacman in a scripting language. if you think c is too lowlevel, then write it in c++, haskell or whatever you want, as long as you can compile it statically so even a glibc upgrade won't be able to kill it :)
Hey there, I've been thinking about libalpm recently since I started maintaining aurbuild. I haven't looked at any of the code of libalpm (yet). Yes, I have heard about how it's ugly and so on. I've seen all the stalled attempts at creating python bindings as well. I contacted one of those projects:
The thing that has to be done before thinking of using pyalpm is implementing the transaction system from libalpm. It'll be a real pain because, until the last time I've checked it, it was made in a "flag-return_value-more_flag" way, which make it very hard to wrap for python (at least using pyrex, as I was). So good luck if you'll try
Well I'm still determined to try just to let you know. I'm willing to provide input and get involved with libalpm eventually. It could be useful for some other archlinux projects too like repoman and pacbuild. And who knows, maybe even a sleek new python based, command-line oriented AUR. I'm stretching, but this is a wacky idea of mine. There was some casual talk among some AUR hackers about hooking into libalpm back in October or something. On Thu, 27 Mar 2008 12:33:18 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
It is clear to us on the list that no one has really latched on to using libalpm. There could be all kinds of different reasons for this, but it's mostly important that libalpm should work for pacman
So, what does this lead us to? 1. Document the existing interface better. Definitely
2. Frontend developers need to speak up and get ideas on this list. Here I am. Though my input will be largely dependent on how my other work progresses. There's only 24 hours in a day unfortunately.
3. Scrap the whole libalpm/split idea. I guess that would depend on the purpose libalpm was created in the first place. If you could ever envision more than one application using the libraries at the same time I would vote to keep libalpm. I can imagine a setup where I have a software checking the database, building, and installing packages in a syncronised manner.
4. Switch to something like python. Though that might make things easier for me (and some others), I don't
It seems that at least one app (shaman) uses libalpm in a serious manner so it would be kind of mean to scrap it. But I guess you can't be nice for nice's sake. Hah. think it would really be a good approach for pacman/libalpm. Unless it was pyrex, or cython maybe hah. But still I'd say no. Cheers!
On Thu, Mar 27, 2008 at 11:28:52PM -0400, Loui <louipc.ist@gmail.com> wrote:
I've been thinking about libalpm recently since I started maintaining aurbuild. I haven't looked at any of the code of libalpm (yet). Yes, I have heard about how it's ugly and so on. I've seen all the stalled attempts at creating python bindings as well.
fwiw, there were working python bindings (and libpacman still has ones), but then problem with it was it violated KISS, so it was removed.
On Fri, 28 Mar 2008 12:37:16 +0100 Miklos Vajna <vmiklos@frugalware.org> wrote:
fwiw, there were working python bindings (and libpacman still has ones), but then problem with it was it violated KISS, so it was removed.
Was that to make libalpm development easier? Do you have any more information? Thanks.
On Fri, Mar 28, 2008 at 9:06 AM, Loui <louipc.ist@gmail.com> wrote:
On Fri, 28 Mar 2008 12:37:16 +0100 Miklos Vajna <vmiklos@frugalware.org> wrote:
fwiw, there were working python bindings (and libpacman still has ones), but then problem with it was it violated KISS, so it was removed.
Was that to make libalpm development easier? Do you have any more information? Thanks.
They were removed because we didn't really do anything on top of what swig output. So we assumed the following: * Anyone could use swig to generate the same bindings * A more focused project for python bindings would do a better job at it
On Fri, Mar 28, 2008 at 4:04 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 28, 2008 at 9:06 AM, Loui <louipc.ist@gmail.com> wrote:
On Fri, 28 Mar 2008 12:37:16 +0100 Miklos Vajna <vmiklos@frugalware.org> wrote:
fwiw, there were working python bindings (and libpacman still has ones), but then problem with it was it violated KISS, so it was removed.
Was that to make libalpm development easier? Do you have any more information? Thanks.
They were removed because we didn't really do anything on top of what swig output. So we assumed the following:
* Anyone could use swig to generate the same bindings * A more focused project for python bindings would do a better job at it
Such a project would probably benefit from browsing this project's source https://gna.org/projects/pynealpm
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
-- A mind all logic is like a knife all blade. It makes the hand bleed that uses it. -- Rabindranath Tagore (1861-1941)
participants (7)
-
Aaron Griffin
-
Dan McGee
-
João Estêvão
-
Loui
-
Miklos Vajna
-
Nagy Gabor
-
Xavier