On Thu, Jun 28, 2012 at 10:10 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 28 June 2012 21:14, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
As you may or may not know, I am currently in the process of teaching Metacello to work with git/github and one of the pieces involves downloading and unzipping directory structure ... at the moment Metacello only works with package dependencies, but it wouldn't be a big leap to be able to manage non-source related dependencies so it might be possible for a configuration to declare a dependency upon a plugin which could be downloaded and moved to the appropriate location via Metacello ...
If that type of facility would be useful, now is a good time to let me know, since I'm hip deep in that code as we speak:)
Hi, Dale. Yes, i think this can be one part of the puzzle. I am unsure however, how you can do that nicely across dialects, because different VMs having different requirements..
But i think this not a big deal, because i know that Metacello already deals with dialect-specific-ness in some way :)
So, here my thoughts about it: actually what we need is to formalize 2 aspects about VM plugins (or/and external libraries in general): - a way to detect what is available - a way to install if that not available
And, We should not assume that we having some centralized "repository" or "registry", because it is futile, considering the zoo of dialects*platforms*different versions.... so defining what/where to download (and making sure it works) should be the responsibility of developer, but not some committee of high priests who deciding what goes/fits into distro and what not.
And, of course i like it to be a) simple b) flexible
:)
This (binary storage problem) will apply to fuel packages in the near future also. And It'll be massive (not something about 30 plugins only).
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, June 28, 2012 11:36:21 AM | Subject: Re: [Pharo-project] VM , modules, packages and plugins | | On 28 June 2012 06:43, Torsten Bergmann <astares@gmx.de> wrote: | >>What i would like to see one day is when i installing new code into | >>image, it pops up a message: | >>"Your VM missing an XYZ plugin for running this cool code, would | >>you | >>like to download and install it? Yes No " | > | > The first problem is that there is no consolidated way to find | > the plugins. Or am I'm missing something. | | Yes. But we should not tolerate a current status quo.. | it starting really pedaling our efforts to improve the situation. | | > | > Remember this: | > | > http://code.google.com/p/pharo/wiki/VMPluginOverview | > http://web.archiveorange.com/archive/v/omFiNcYAwvI6GB8z7r1j | > | yes, thanks for reminder. | | > As ever it is a question of time to define and implement a | > working process. | > | | So, my vision that it should not be something external which user(s) | must download | and install separately and manually. Does everyone knows that page | exists? | Or, actually, why users must be concerned about those details: if | they | found a way to load | the code which using plugin, the rest should be NOT of their concern, | a system must | do the rest automatically. | | The code, which using the plugin SHOULD have the knowledge about how | to locate the plugin | and install it, and of course, which version of it to use. | This , i think, could kill many hurdles in distribution process and | improve user's experience. | | > Bye | > T. | > -- | > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! | > Jetzt informieren: | > http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a | > | | | | -- | Best regards, | Igor Stasenko. | |
-- Best regards, Igor Stasenko.