Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
Greets Markus
Hi Markus,
I'm the main developer of Aqpm, a Qt/C++ wrapper of alpm, which is also the library behind Shaman. Your project seems great, and I hope somebody will use it to make something just as great!
However, I wanted to let you know that at the moment Alpm behaves strangely in multithreaded environments. Particularly (I don't know why and I did not investigate further), when running package scriptlets the operation will stall completely if more than one thread is active.
You might want to consider this in your library, in Aqpm there's no such problem as by using PolicyKit, transactions are always jailed in a different process which is of course single-threaded, and that's probably the only solution.
I would suggest you to make some tests of pyalpmm in multithreaded environments, since the highest barrier of alpm in GUI ambits is that it was not designed with thread usage in mind. Also have a look at Aqpm, which is completely thread-safe, as I jailed alpm as well in its very own thread, you might be tempted to adopt a similar solution.
Hope this helped you!
In data sabato 22 agosto 2009 16:45:14, Markus Meissner ha scritto: : > Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
Greets Markus
Hey Dario,
Ok, nice this makes one big new point on my todo list.
So did I understand you right and the problems only occur during a transaction? That means all the database-querying stuff works fine without further consideration in multi-threaded environments?
But the idea of jailing the transaction in a separate process is quite interesting, but where is the point in putting alpm in a separate thread? Does this mean, that other non-transaction stuff also makes problems in some situations?
Greets Markus
Dario Freddi wrote:
Hi Markus,
I'm the main developer of Aqpm, a Qt/C++ wrapper of alpm, which is also the library behind Shaman. Your project seems great, and I hope somebody will use it to make something just as great!
However, I wanted to let you know that at the moment Alpm behaves strangely in multithreaded environments. Particularly (I don't know why and I did not investigate further), when running package scriptlets the operation will stall completely if more than one thread is active.
You might want to consider this in your library, in Aqpm there's no such problem as by using PolicyKit, transactions are always jailed in a different process which is of course single-threaded, and that's probably the only solution.
I would suggest you to make some tests of pyalpmm in multithreaded environments, since the highest barrier of alpm in GUI ambits is that it was not designed with thread usage in mind. Also have a look at Aqpm, which is completely thread-safe, as I jailed alpm as well in its very own thread, you might be tempted to adopt a similar solution.
Hope this helped you!
In data sabato 22 agosto 2009 16:45:14, Markus Meissner ha scritto: : > Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
Greets Markus
Hi Markus,
In data domenica 23 agosto 2009 19:45:48, Markus Meissner ha scritto: : > Hey Dario,
Ok, nice this makes one big new point on my todo list.
So did I understand you right and the problems only occur during a transaction? That means all the database-querying stuff works fine without further consideration in multi-threaded environments?
Yes, given that you control race conditions. Every function is not thread- safe.
But the idea of jailing the transaction in a separate process is quite interesting, but where is the point in putting alpm in a separate thread? Does this mean, that other non-transaction stuff also makes problems in some situations?
No, it does not; I just wanted to make sure that Aqpm was completely thread- safe, since with the old Shaman I had a problem with some race conditions making it crash on multiple queries. This point really depends on what is your final target: if you plan to develop a full-fledged frontend à-la-Shaman, my advice is to go for thread-safety.
Python probably won't suffer from some problems I run into (and I wrote Shaman when I was much less capable of coding and less experienced, and you can tell it :) ), but the best way (to me) is to see first how pyalpmm reacts in multithreaded environments by making some unit tests, and then decide. This would save your time and prevent eventual future problems.
Greets Markus
Dario Freddi wrote:
Hi Markus,
I'm the main developer of Aqpm, a Qt/C++ wrapper of alpm, which is also the library behind Shaman. Your project seems great, and I hope somebody will use it to make something just as great!
However, I wanted to let you know that at the moment Alpm behaves strangely in multithreaded environments. Particularly (I don't know why and I did not investigate further), when running package scriptlets the operation will stall completely if more than one thread is active.
You might want to consider this in your library, in Aqpm there's no such problem as by using PolicyKit, transactions are always jailed in a different process which is of course single-threaded, and that's probably the only solution.
I would suggest you to make some tests of pyalpmm in multithreaded environments, since the highest barrier of alpm in GUI ambits is that it was not designed with thread usage in mind. Also have a look at Aqpm, which is completely thread-safe, as I jailed alpm as well in its very own thread, you might be tempted to adopt a similar solution.
Hope this helped you!
In data sabato 22 agosto 2009 16:45:14, Markus Meissner ha scritto: : > Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
Greets Markus
On Sat, Aug 22, 2009 at 4:45 PM, Markus Meissnermarkus@evigo.net wrote:
Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
And I just read the announcement of a graphical interface based on your project : http://bbs.archlinux.org/viewtopic.php?id=79764
I did not try pyalpmm myself, but it is a very good news that we finally seem to have working python bindings, that other people managed to use :) I know there were several attempts before, but it didn't look like they went that far.
Hey guys,
after this neat announcement, since it looks like we're about to have a great GUI for alpm with GTK+, I think I could take the big step and make Shaman hard-depend on kdelibs for the next version (1.3). In fact many of the changes I'm making really require a lot of hassle to keep the Qt only and KDE version play together.
Please share your opinion (given that Shaman is inside community, too). Do you think it is worth it/can create problems to make Shaman hard depend on KDELibs?
In data martedì 08 settembre 2009 17:28:27, Xavier ha scritto: : > On Sat, Aug 22, 2009 at 4:45 PM, Markus Meissnermarkus@evigo.net wrote:
Hello pacman-dev list members,
I'm the developer (meissna) behind the python libalpm wrapper: pyalpmm You can find more information in this thread (1st post): http://bbs.archlinux.org/viewtopic.php?id=60711&p=1
As a very short abstract: pyalpmm implements a thin very high level wrapper around the alpm library written in python.
One of the main goals in the medium term are a transparent regular repos and aur support ... (like mixing aur and repo packaged in -S) Several steps are taken towards this goal, like building (mmacman -BI some_repo_or_aur_pkg) supports both transparently, searching ( mmacman -Ss query) also supports both: regular repos and aur. The next step is already the "-S functionality" milestone, which needs proper AUR pkg dependency resolution - this is in construction, or maybe "conception" ;)
And, dunno if this is usual, but one line about me personally: My name is Markus Meissner, living and studying in Germany/Frankfurt - right now I'm in Munich for my graduation and I'm 25years old...
So, hi all!
And I just read the announcement of a graphical interface based on your project : http://bbs.archlinux.org/viewtopic.php?id=79764
I did not try pyalpmm myself, but it is a very good news that we finally seem to have working python bindings, that other people managed to use :) I know there were several attempts before, but it didn't look like they went that far.
Dario Freddi wrote:
Hey guys,
after this neat announcement, since it looks like we're about to have a great GUI for alpm with GTK+, I think I could take the big step and make Shaman hard-depend on kdelibs for the next version (1.3). In fact many of the changes I'm making really require a lot of hassle to keep the Qt only and KDE version play together.
Please share your opinion (given that Shaman is inside community, too). Do you think it is worth it/can create problems to make Shaman hard depend on KDELibs?
Firstly, I quite like the dichotomy that current happens with shaman - in Arch [community] repo it is Qt only while in Chakra it is more fully integrated as part of the KDEmod experience.
From a non-KDE users perspective, I would no longer consider using Shaman if it depended on kdelibs given that is a fairly bulky package. The Qt dep is fairly easily justified even for a user who is primarily in a GTK+ desktop as it is probably used for something like Skype anyway.
But if using kdelibs would make supporting shaman a lot easier, then I know what I would be doing...
Allan
pacman-dev@lists.archlinux.org