[Pharo-project] documentation for "blessed" pharo repositories?
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information? Cheers, Esteban
On 3 February 2011 14:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information?
I think best would be to put it close to code. I mean In some class comment: - my official location is _here_ use it , or get out of my sight :) And of course we having metacello configs. I think for builds, we could create something which generating the configurations by extracting the official locations from some package class.. So, by implementing tools which can do: MyPackageInfo officialLocation MyPackageInfo createMetacelloConfiguration: ConfigurationOfMyPackage we can avoid manual steps, which lead to mistakes. What i tried to do is to directly extract package information form current image and compose a script which loads exactly same package you are using in your image. So, then such script could be used to reproduce your configuration. Actually i wonder, if this feature could be added to Metacello.. So you could tell something like: ConfigurationOfMyPackage createSnapshotForNewVersion so, it will capture the state of packages in current image and generate new #versionXYZ: at instance side, which reflects it.
Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
Igor, I am willing to add new features to Metacello to make the development process run smoother. The MetacelloToolBox has a number of methods for programmatically building configurations and creating new versions and I have Metacello support for copying configurations files to different repositories and automatically saving dirty mcz files, so many of the features that you are talking about may already be there. The MetacelloToolBox is documented here: http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed... The current toolbox api pretty much reflects my working style, but I am willing to extend/expand the api to support a broader range of requirements. Dale On Feb 3, 2011, at 6:54 AM, Igor Stasenko wrote:
On 3 February 2011 14:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information?
I think best would be to put it close to code. I mean In some class comment: - my official location is _here_ use it , or get out of my sight :)
And of course we having metacello configs.
I think for builds, we could create something which generating the configurations by extracting the official locations from some package class..
So, by implementing tools which can do: MyPackageInfo officialLocation MyPackageInfo createMetacelloConfiguration: ConfigurationOfMyPackage
we can avoid manual steps, which lead to mistakes.
What i tried to do is to directly extract package information form current image and compose a script which loads exactly same package you are using in your image. So, then such script could be used to reproduce your configuration.
Actually i wonder, if this feature could be added to Metacello..
So you could tell something like:
ConfigurationOfMyPackage createSnapshotForNewVersion
so, it will capture the state of packages in current image and generate new #versionXYZ: at instance side, which reflects it.
Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
On 3 February 2011 18:16, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I am willing to add new features to Metacello to make the development process run smoother.
The MetacelloToolBox has a number of methods for programmatically building configurations and creating new versions and I have Metacello support for copying configurations files to different repositories and automatically saving dirty mcz files, so many of the features that you are talking about may already be there.
The MetacelloToolBox is documented here:
 http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed...
The current toolbox api pretty much reflects my working style, but I am willing to extend/expand the api to support a broader range of requirements.
Yeah , that's actually what i thinking about: MetacelloToolBox saveModifiedPackagesIn: ConfigurationOfGemToolsExample description: '- fixed Issue 1090'. so, that's cool, except that i have to learn Metacello before starting using it for real. You know we are all very-very busy people. But i would really like to create a VMMaker configs, which will work out of the box.. so it has to be done once :)
Dale
-- Best regards, Igor Stasenko AKA sig.
thanks dale I should finish the chapter. But I got two projects to write for the 18th, so after :) On Feb 3, 2011, at 6:16 PM, Dale Henrichs wrote:
Igor,
I am willing to add new features to Metacello to make the development process run smoother.
The MetacelloToolBox has a number of methods for programmatically building configurations and creating new versions and I have Metacello support for copying configurations files to different repositories and automatically saving dirty mcz files, so many of the features that you are talking about may already be there.
The MetacelloToolBox is documented here:
http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed...
The current toolbox api pretty much reflects my working style, but I am willing to extend/expand the api to support a broader range of requirements.
Dale
On Feb 3, 2011, at 6:54 AM, Igor Stasenko wrote:
On 3 February 2011 14:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information?
I think best would be to put it close to code. I mean In some class comment: - my official location is _here_ use it , or get out of my sight :)
And of course we having metacello configs.
I think for builds, we could create something which generating the configurations by extracting the official locations from some package class..
So, by implementing tools which can do: MyPackageInfo officialLocation MyPackageInfo createMetacelloConfiguration: ConfigurationOfMyPackage
we can avoid manual steps, which lead to mistakes.
What i tried to do is to directly extract package information form current image and compose a script which loads exactly same package you are using in your image. So, then such script could be used to reproduce your configuration.
Actually i wonder, if this feature could be added to Metacello..
So you could tell something like:
ConfigurationOfMyPackage createSnapshotForNewVersion
so, it will capture the state of packages in current image and generate new #versionXYZ: at instance side, which reflects it.
Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
Also, if there is a deprecated repositoriy: - put a comment clearly stating that the directory is intended to be closed and read only - indicate where further work should take place. You have the main web tab, the wiki. I also suggest to publish a last MC version for the main packages with no change, and a commit comment indicating new location. Nicolas 2011/2/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
thanks dale I should finish the chapter. But I got two projects to write for the 18th, so after :)
On Feb 3, 2011, at 6:16 PM, Dale Henrichs wrote:
Igor,
I am willing to add new features to Metacello to make the development process run smoother.
The MetacelloToolBox has a number of methods for programmatically building configurations and creating new versions and I have Metacello support for copying configurations files to different repositories and automatically saving dirty mcz files, so many of the features that you are talking about may already be there.
The MetacelloToolBox is documented here:
 http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed...
The current toolbox api pretty much reflects my working style, but I am willing to extend/expand the api to support a broader range of requirements.
Dale
On Feb 3, 2011, at 6:54 AM, Igor Stasenko wrote:
On 3 February 2011 14:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information?
I think best would be to put it close to code. I mean In some class comment: - my official location is _here_ use it , or get out of my sight :)
And of course we having metacello configs.
I think for builds, we could create something which generating the configurations by extracting the official locations from some package class..
So, by implementing tools which can do: MyPackageInfo officialLocation MyPackageInfo createMetacelloConfiguration: ConfigurationOfMyPackage
we can avoid manual steps, which lead to mistakes.
What i tried to do is to directly extract package information form current image and compose a script which loads exactly same package you are using in your image. So, then such script could be used to reproduce your configuration.
Actually i wonder, if this feature could be added to Metacello..
So you could tell something like:
ConfigurationOfMyPackage createSnapshotForNewVersion
so, it will capture the state of packages in current image and generate new #versionXYZ: at instance side, which reflects it.
Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
good idea! Stef On Feb 3, 2011, at 7:19 PM, Nicolas Cellier wrote:
Also, if there is a deprecated repositoriy: - put a comment clearly stating that the directory is intended to be closed and read only - indicate where further work should take place. You have the main web tab, the wiki. I also suggest to publish a last MC version for the main packages with no change, and a commit comment indicating new location.
Nicolas
2011/2/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
thanks dale I should finish the chapter. But I got two projects to write for the 18th, so after :)
On Feb 3, 2011, at 6:16 PM, Dale Henrichs wrote:
Igor,
I am willing to add new features to Metacello to make the development process run smoother.
The MetacelloToolBox has a number of methods for programmatically building configurations and creating new versions and I have Metacello support for copying configurations files to different repositories and automatically saving dirty mcz files, so many of the features that you are talking about may already be there.
The MetacelloToolBox is documented here:
http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed...
The current toolbox api pretty much reflects my working style, but I am willing to extend/expand the api to support a broader range of requirements.
Dale
On Feb 3, 2011, at 6:54 AM, Igor Stasenko wrote:
On 3 February 2011 14:02, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi, There is new repositories for pre-existing packages like PharoOB, Filesystem, PharoSound. As in the future this repositories can grow, and people like me can be confused... I wonder if we can add a page somewhere with this information?
I think best would be to put it close to code. I mean In some class comment: - my official location is _here_ use it , or get out of my sight :)
And of course we having metacello configs.
I think for builds, we could create something which generating the configurations by extracting the official locations from some package class..
So, by implementing tools which can do: MyPackageInfo officialLocation MyPackageInfo createMetacelloConfiguration: ConfigurationOfMyPackage
we can avoid manual steps, which lead to mistakes.
What i tried to do is to directly extract package information form current image and compose a script which loads exactly same package you are using in your image. So, then such script could be used to reproduce your configuration.
Actually i wonder, if this feature could be added to Metacello..
So you could tell something like:
ConfigurationOfMyPackage createSnapshotForNewVersion
so, it will capture the state of packages in current image and generate new #versionXYZ: at instance side, which reflects it.
Cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Dale Henrichs -
Esteban Lorenzano -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse