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 :)

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.

Igor, embedded comments... ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, June 28, 2012 1:10:50 PM | Subject: Re: [Pharo-project] VM , modules, packages and plugins | | 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 :) Yes we have options there ... I do have access to the Metacello internals:), so we shouldn't try to shoehorn the requirements into existing slots (unless they fit nicely) ... pre&post load actions already exist ... conditional platform logic already exists ... the main challenge for a `plugin` entity would be to avoid trying to load it ... so I think it would be something that could be done given a compelling use case. | | 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 Yes, these are the challenges. The idea behind Metacello is that the primary developer is able to make the decision ("detect what is available") and specify the explicit version and location of the plugin for download. Which leaves "a way to install if that not available" ... which is presumably challenge enough:) | | 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. Exactly ... for "optional plugins" it has to be the project maintainer(s) who are responsible for vetting the which plugin works with their code as the coupling between the plugin and code is pretty tight ... | | | And, of course i like it to be | a) simple | b) flexible | | :) Don't we all:) | | > | > 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. | |