You are not logged in.
Pages: 1
Modularized (libified) yaourt
Hi, while trying to hack yaourt to more suit my needs I came to the understanding that keeping yaourt as one file makes it a bit difficult to understand and change it by third-parties (don't know how about the author).
So before modifying it any further, I've decided to split it up into modules (or libraries) to ease maintaining and hacking.
That's where I got so far [1].
Please test it to ensure that I haven't missed anything (probably the symtoms are bash complaints about undefined commands)
This tarball is often updated, so if anything goes wrong, try redownloading it before shouting at me
Quick summary of the work
This is a script functionally similar to yqourt-0.8.3 (last to the dat of writing), split up in a number of files (called libraries or modules), loaded on demand by issuing 'source'. The appropriate changes are made to the main `yaourt' script
How to test
Download the archive, untar.
Run the beast as ./yaourt.sh [options]
It's behaviour should be identical to stock yaourt's. If anything goes wrong, ping me on irc or by email or post here.
Disclaimer
This is currenlty in developer-only stage, as it doesn't have any user-visible changes yet and might be harmful to your system (though not more than a stock yaourt I believe)
[1] http://olegfink.hovel.ru/modularized-yaourt.tar.gz
Last edited by olegfink (2007-08-02 18:28:55)
Offline
Good work!
Offline
Interesting
Offline
okay, till now I've only separated functions. Now I will try to move some code from the main program to functions as well.
Offline
Hello olegfink, I just come back from holidays
A modularized yaourt ? why not
I began this split a long time while leaving pacdiffviewer, aurvote and customizepkg out of yaourt.
But do not hesitate to explain to me what you would like to add in yaourt. I've seen your comment on aur page about exporting the whole build tree. I will add an option in yaourtrc for that.
I noticed that some functions are missing in modularized-yaourt like upgrade_from_aur.
Offline
Hi wain, pleased to meet you
The split is good, so I'm doing it.
My ultimate goal is to try adding the missing pacman functionality to yaourt (in fact you almost never use pacman, preferring to work with the database directly, Also you handle dependencies by yourself (I think I've seen this code in aur), so it's not much trouble concerning that we have a shell pacman implementation (one that Fakebox uses). Thanks for adding export. In fact maybe instead of an export option I would like yaourt to build everything in /var/abs/local and then have an option to leave everything there.
About missing functions: they are not missing, but due to my recent recstructurization (from media scheme (abs,aur) to operational scheme (install,upgrade,search) I sometimes load wrong libraries. I will fix every issue as I see it.
More about what I'm doing: in fact I want yaourt to become a complete Arch packaging solution and as such I want to make some sort of an abstraction level for its functions (like install which decides whether to build package or get it from repos).
However, I don't really want to fork yaourt, so I really appreciate your feedback and suggest you to review my work and see if it is worth continuing.
Thanks.
Last edited by olegfink (2007-08-01 13:22:52)
Offline
Impressed. I like what you're doing.
Havn't looked at the code, but i'm looking forward to being able to use the functions of yaourt in my own scripts.
James
Offline
Hi wain, pleased to meet you
The split is good, so I'm doing it.
My ultimate goal is to try adding the missing pacman functionality to yaourt
Me too
(in fact you almost never use pacman, preferring to work with the database directly, Also you handle dependencies by yourself (I think I've seen this code in aur), so it's not much trouble concerning that we have a shell pacman implementation (one that Fakebox uses).
yaourt will use libalpm as soon as possible to have the best performance and compatibility. That will result a smaller code, more compact and easy to read/improve.
Your yaourt's split in 20 small files (aur.sh, configfile.sh, database.sh, output.sh, pkgbuild.sh, search.sh, upgrade.sh, versions.sh, build.sh, control.sh, install.sh, orphans.sh, params.sh, query.sh, su.sh, usage.sh, vote.shaur.sh) is interesting but some files are loaded and reloaded too many times: query, aur for example.
Maybe you could merge some files, for example:
- database.sh and query.sh in => use_database.sh
- vote.sh and aur.sh => use_aur.sh
- create_ignorepkg_list (in control.sh) is not in a good place
...
If someone (like iphitus) want to reuse yaourt librairies, the split must be done with this goal in mind. Functions proper to yaourt in one corner, functions usable by external scripts in the other. It becomes gradually a shell implementation of "libalpm+aur support" we can call it libalpm-sh; and the client on top: yaourt.
That still requires some reflexion
Offline
yaourt will use libalpm as soon as possible to have the best performance and compatibility. That will result a smaller code, more compact and easy to read/improve.
How do you plan to use a C library from a shell script? Is it at all possible?
Your yaourt's split in 20 small files (aur.sh, configfile.sh, database.sh, output.sh, pkgbuild.sh, search.sh, upgrade.sh, versions.sh, build.sh, control.sh, install.sh, orphans.sh, params.sh, query.sh, su.sh, usage.sh, vote.shaur.sh) is interesting but some files are loaded and reloaded too many times: query, aur for example.
Maybe you could merge some files, for example:
- database.sh and query.sh in => use_database.sh
- vote.sh and aur.sh => use_aur.sh
Thanks for the suggestion, I'll surely do what you've proposed. However, if you look at use() in yaourt, you would see that I tried to enable some kind of re-include-protection (similar to C's "#ifndef ... #define... #endif"), so every file is sourced only once in fact.
- create_ignorepkg_list (in control.sh) is not in a good place
Where should it be placed, in your opinion?
If someone (like iphitus) want to reuse yaourt librairies, the split must be done with this goal in mind. Functions proper to yaourt in one corner, functions usable by external scripts in the other. It becomes gradually a shell implementation of "libalpm+aur support" we can call it libalpm-sh; and the client on top: yaourt.
That still requires some reflexion
Would you want to continue my split? Or it'd be smarter for me to just drop it and wait for you to implement it the way you want?
I'm open for any kinds of collaboration though, I think I can set up a git/bzr/svn repo if you (or someone else) wants to continue the work. Or maybe use projects.archlinux.org?
Thanks, and just keep up yaourt development, either splitted up or not
Offline
renamed yaourt to yaourt.sh without any obvious reason. Edited the first post to reflect this.
Also, what is the final decision about grouping scheme? wain? iphitus?
Use media-based (aur.sh with search/build/upgrade/vote/etc and database with clear/search/backup aso) or task-based (query,search with both database and aur backends, install (both pkg and aur) etc?)
Last edited by olegfink (2007-08-02 18:33:21)
Offline
How do you plan to use a C library from a shell script? Is it at all possible?
No we have to write a wrapper
create_ignorepkg is only used to install package, so install.sh seems to be a good place :-)
Would you want to continue my split? Or it'd be smarter for me to just drop it and wait for you to implement it the way you want?
I'm open for any kinds of collaboration though, I think I can set up a git/bzr/svn repo if you (or someone else) wants to continue the work. Or maybe use projects.archlinux.org?Thanks, and just keep up yaourt development, either splitted up or not
We (archlinux.fr users) where about to open a git repository for contributions, so I'm sure we can work together on this split with git. Maybe I have above all to cleanup the code and add comments to facilitate the collaboration.
Offline
create_ignorepkg is only used to install package, so install.sh seems to be a good place :-)
okay
We (archlinux.fr users) where about to open a git repository for contributions, so I'm sure we can work together on this split with git. Maybe I have above all to cleanup the code and add comments to facilitate the collaboration.
Would be extremely nice
looking forward for a collaboration
EDIT: do you want to set your one or use projects.archlinux.org (seems this site needs some popularization)
Last edited by olegfink (2007-08-02 18:36:05)
Offline
EDIT: do you want to set your one or use projects.archlinux.org (seems this site needs some popularization)
I was under the impression that projects.archlinux.org was for arch-official projects only.
Offline
I was under the impression that projects.archlinux.org was for arch-official projects only.
Well, then it's not for me.
Last edited by olegfink (2007-08-02 19:14:24)
Offline
Pages: 1