dragora-members
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dragora-members] Relation of Qi and Qire


From: Matias Fonzo
Subject: Re: [Dragora-members] Relation of Qi and Qire
Date: Wed, 17 Jun 2020 19:53:15 -0300
User-agent: Roundcube Webmail/1.4.4

El 2020-06-16 17:23, Michael Siegel escribió:
Am 16.06.20 um 18:16 schrieb Matias Fonzo:

I'm sorry, I realized that it's better to incorporate parts of Qire into
Qi and invoke them after you suggested the single command, maybe I
didn't get it right.

Okay, I see.

Could you explain the relation of Qi and Qire how you currently envision
it for Dragora 3 once again as if you were trying to explain it to
someone who has no prior knowledge of those things? That will surely
help to cure my confusion.

Well... Qi is the package manager, to build, install, remove or update
distributed software or binary packages.  Qi uses the Graft for package
management or control, which can be used separately for finer package
management.  Qire is the remote extension of Qi for managing or
obtaining binary packages over the Internet.

And for most of the day-to-day package management, you would only have
to run Qi, right? So, would the relation of Qi and Qire be similar to
that of Graft and Qi then? By that I mean: For most usual tasks, you
would only have to run Qi, but if you needed to do more elaborate work
with remote repositories, you would probably have to switch to using
Qire directly.

Is that what you mean?

Yes, correct.

If so, I'm not really sure this is a solid concept. But we could just
try it and see.

If they are going to invoke Qi most of the day, that's why I think it's better to use the parts of Qire, like "qi update" or "qi repo", or "qi <whatever>" that correspond to Qire...

About rewriting Qi: While I would agree that Qi should not be rewritten for Dragora 3, I think there is one good reason to rewrite Qi in a more suitable language at some later point. And that is that, ultimately, Qi
should also offer a GUI, in my opinion.


I'd like to do one, maybe in Tcl/Tk.  But I don't have the energy or the
knowledge to do that right now either.

Yeah, no problem. I see it more as a long-term goal.

Tk is a good choice, I think. It can also be used from Perl, Python,
Ruby, Scheme and, I think, some other languages.


Michael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]