[Pharo-project] Gofer vs Installer
What is the difference in: goals? implementation? speed? license? other aspects? I can see that they both can install packages in a pharo image. Thanks -- Miguel Cobá http://miguel.leugim.com.mx
For Gofer:
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
implementation?
Focus on keeping the system clean, e.g. no empty categories/protocols, properly ordered categories/protocols, no duplicated repositories, etc.
speed?
Not optimized yet.
license?
MIT Lukas -- Lukas Renggli http://www.lukas-renggli.ch
El sáb, 19-09-2009 a las 18:34 +0200, Lukas Renggli escribió:
For Gofer:
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader? Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo. Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful. Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it?? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages. Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The first thing you can try is to check using the browse button of MC that you extensions methods are well in your package. Stef On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote:
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful.
Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I've done that, but my understanding is that "all" it does is show the methods that are packaged. I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:03 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer The first thing you can try is to check using the browse button of MC that you extensions methods are well in your package. Stef On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote:
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful.
Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok I will I do not have the snipped at hand that can check all the dirty methods. Could you add that to bug traker with a request for feature because indeed this is a nice one. Stef On Sep 20, 2009, at 8:24 AM, Schwab,Wilhelm K wrote:
Stef,
I've done that, but my understanding is that "all" it does is show the methods that are packaged. I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:03 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
The first thing you can try is to check using the browse button of MC that you extensions methods are well in your package.
Stef
On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote:
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful.
Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, It is listed as 1229. I added a brief mention of using a list of packages to generate a load script. If I understand our current level of dependency control, it would probably be best to have an explicit list that would be litle more than a build script expressed in objects (perhaps living in a class method named for the author or something like that) that would be used to write a load script and aid the search for dirty methods. I'm not sure how helpful any of that is :) Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:50 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer Ok I will I do not have the snipped at hand that can check all the dirty methods. Could you add that to bug traker with a request for feature because indeed this is a nice one. Stef On Sep 20, 2009, at 8:24 AM, Schwab,Wilhelm K wrote:
Stef,
I've done that, but my understanding is that "all" it does is show the methods that are packaged. I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 1:03 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
The first thing you can try is to check using the browse button of MC that you extensions methods are well in your package.
Stef
On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote:
I'd like to put on my user hat for a moment. A big concern of mine is doing a good job of saving packages from one image and moving them to another. I have (hopefully) been keeping my install script current as I add new packages, but it currently relies on my being careful.
Clearly having very good coverage with tests would help to check the health of any new image; I'm slowly working on that. It would be nice to have ways to check for packaging mistakes. A "smell" that comes to mind is any methods that I wrote but are not in packages in my load script. Is there anything that does such checks? Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've done that, but my understanding is that "all" it does is show the methods that are packaged. Â I am hoping for something that would sniff out the methods that I have altered and are not in packages that I (somehow) claim to own. Â It seems like it would be really easy to miss important work and that it should be relatively easy to create something that scans for at-risk code. Â One thing I can enivision would compare a list of packages with user-owned methods in the system; anything that is not in one of the packages goes in a method browser with commands to package them in likely places.
The refactoring Code Checker reliably detects unpackaged code, see Possible Bugs > Unpackaged Code. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
 Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism.  This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at  Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Sounds great! Is it downloadable? -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, September 20, 2009 1:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
 Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism.  This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it. Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at  Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
from source.lukasrenggli.com/flair I'm about to write a chapter on it for PharoByexample2 Stef On Sep 20, 2009, at 8:30 AM, Schwab,Wilhelm K wrote:
Sounds great! Is it downloadable?
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Sunday, September 20, 2009 1:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it.
Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Definitively not well woken up yet :)
from source.lukasrenggli.com/flair
I'm about to write a chapter on it for PharoByexample2
Stef
On Sep 20, 2009, at 8:30 AM, Schwab,Wilhelm K wrote:
Sounds great! Is it downloadable?
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Sunday, September 20, 2009 1:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism. This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it.
Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ScriptLoader loadLatestPackage: 'Gofer' from: 'http://source.lukas-renggli.ch/flair'. 2009/9/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sounds great! Â Is it downloadable?
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, September 20, 2009 1:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
 Seaside 2.9 includes a tool that helps to manage packages, and _somewhere_ I have an image with that loaded and ready for shameless plagairism.  This seems like such a common task that there must be some good tools to handle it??
That's exactly Gofer. Seaside 3 is one of the reasons why I wrote it.
Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Saturday, September 19, 2009 4:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
Stephane has mentioned Gofer before. Is in the plans to support only MC packages for Pharo and to use Gofer as the tool for load them on pharo.
Yes. Because in pharo we do not use anything else besides on changeset to kick in the load.
Or nothing has been decided yet? It is considered?
implementation?
Focus on keeping the system clean, e.g. no empty categories/ protocols, properly ordered categories/protocols, no duplicated repositories, etc.
Installer can't do that? Is a question, I don't know much about the internals of Installer.
Compared to sometimes ago they were cleaned but
speed?
Not optimized yet.
license?
MIT
Can you please give us a big picture of the role Gofer will have?
After discussion at  Esug between dale, lukas and me listening :) it seems that Metacello will use Gofer to load packages.
Now I think that you should give a try to Gofer and report what is missing or not. I have some behvaior I would really like to have (that are specific to ScriptLoader like tell me which packages have changed since a given marked period).
Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote:
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
I always thought that you guys didnt actually understand installer. Installer is intended to fulfill a strategic role, it has a role "Installing things", and it is extensible, so that anyone else who wants to "Install things" can contribute to it and extend it. So when a user wants to Install things, there is a logical place to go, that is called "Installer" for installing things. If you want to create an additional tool for "installing things" then why not consider how this tool may provide facilities for installer. Otherwise this indicates that the whole design concept and envisioned role of Installer has been overlooked. There is nothing wrong with ScriptLoader per se, but to be consistent with the vision for Installer it would be provided as an extension to Installer, thus... Installer scriptloader doWhateverYouWantHere. Installer was created to be the first and only dependency for kernel images of any kind, that you can use to load additional things. You guys come along and use ScriptLoader for roughly this purpose, thus explicitly ignoring, and implicitly undermining this goal from the outset. Furthermore none of your scripts in script loader appear to take advantage of the second installer feature. which is... Installer is supposed to enable scripts to be written and executed piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. Installer scripts do not , and should not use temporaries. i.e. this style of code is NOT suitable for this purpose. | repo | repo := Installer squeaksource project: 'This'. repo install: 'That'. A better code example which has no method temporaries is shown below Installer squeaksource project: 'This'; install: 'That'. Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. Installer mine project: 'This'; install: 'That'. Installer is supposed to provide a uniform API as a front end for all code loading tools so if this new gofer thing comes along, its API (implemented on InstallerGofer perhaps) could be published as Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; install. or Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; merge. I think that it would be a shame if the gofer tool whatever it is, doesn't come with an Installer api, then it would not be contributing to the Installer story, it would be competing with it, in the same strategic space. Given the fragmentation that is continuing to occur in the speak community, I think that this is tragic, that we end up with so many re- inventions of the wheel, yet none of them actually fulfills the role that, if you sit down and think about it for a few minutes, we actually need I.e. the original invention of Installer was expressly so that EVERY base image published would at least have Installer loaded (or loadable) and users could build from there, using whatever tools, and a consistent API. Installer helps this along in some situations since it knows how to load the source from an MC package in the event that MC is not actually loaded, and this helps with bootstapping Monticello etc. If everyone uses, or has the option of using the same tools for building images, in every release, then this facilitates exchange of packages among forks, and helps those of us who are not at liberty to jump ship on a whim, and it helps those who do want to jump ship on a whim. I was asking you for months to think along these lines and make such strategic choices based upon contributing to things that the squeak communities have in common or might want to use in common... The vision for Installer was to be a base for building derived images in all release images in all forks. The vision for MC1.5 was to be a set of tools that actually worked to load code in all images in all forks. The vision for LevelPlayingField is to provide bootstrapping for difficult code to load in all images in all forks. The vision for Sake/Packages was to be a universal set of package definitions and dependencies that show what works where in ALL images, in ALL Forks. The vision for SUnit-improved was to be a universal means for defining SUnit and SSpec tests for ALL images so that it is possible to indicate what works where, in ALL forks, so that packages of tests can be maintained in common for ALL forks. So, may I appeal to you, please contribute to and use installer, rather than compete with it, and perhaps reconsider your approach to the other ideas listed above. Keith p.s. I am considering, recruiting members for an independant "guild" of package developers, whose role would be to promote interoperability between squeak forks, so that packages can be developed once and deployed anywhere. I think this is needed because now we have no core image developers in either squeak or pharo, that look at interoperability.
2009/9/21 keith <keith_hodges@yahoo.co.uk>:
On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote:
goals?
Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages.
So, not like Installer that can load packages from everywhere, Gofer will concentrate on MC? What about ScriptLoader?
ScriptLoader will certainly use gofer to install packages instead of installer
I always thought that you guys didnt actually understand installer.
Which is partly your own fault. As for the rest of post i agreeing with you. Except, maybe that Gofer may be targeted not only as cross-fork but for cross-dialect tool. But i don't have any info on that, and indeed, i think Installer , with some refactorings could also work as a cross-dialect tool, at least on platforms which already supporting MC.
Installer is intended to fulfill a strategic role, it has a role "Installing things", and it is extensible, so that anyone else who wants to "Install things" can contribute to it and extend it. So when a user wants to Install things, there is a logical place to go, that is called "Installer" for installing things.
If you want to create an additional tool for "installing things" then why not consider how this tool may provide facilities for installer. Otherwise this indicates that the whole design concept and envisioned role of Installer has been overlooked.
There is nothing wrong with ScriptLoader per se, but to be consistent with the vision for Installer it would be provided as an extension to Installer, thus...
Installer scriptloader doWhateverYouWantHere.
Installer was created to be the first and only dependency for kernel images of any kind, that you can use to load additional things.
You guys come along and use ScriptLoader for roughly this purpose, thus explicitly ignoring, and implicitly undermining this goal from the outset. Furthermore none of your scripts in script loader appear to take advantage of the second installer feature.
which is...
Installer is supposed to enable scripts to be written and executed piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. Installer scripts do not , and should not use temporaries.
i.e. this style of code is NOT suitable for this purpose.
| repo |
    repo := Installer squeaksource project: 'This'.
    repo install: 'That'.
A better code example which has no method temporaries is shown below
Installer squeaksource project: 'This'; install: 'That'. Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. Installer mine project: 'This'; install: 'That'.
Installer is supposed to provide a uniform API as a front end for all code loading tools
so if this new gofer thing comes along, its API (implemented on InstallerGofer perhaps) could be published as
Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; install.
or
Installer gofer project: 'This'; addPackage: 'That'; addPackage: 'TheOther'; merge.
I think that it would be a shame if the gofer tool whatever it is, doesn't come with an Installer api, then it would not be contributing to the Installer story, it would be competing with it, in the same strategic space.
Given the fragmentation that is continuing to occur in the speak community, I think that this is tragic, that we end up with so many re- inventions of the wheel, yet none of them actually fulfills the role that, if you sit down and think about it for a few minutes, we actually need
I.e. the original invention of Installer was expressly so that EVERY base image published would at least have Installer loaded (or loadable) and users could build from there, using whatever tools, and a consistent API. Installer helps this along in some situations since it knows how to load the source from an MC package in the event that MC is not actually loaded, and this helps with bootstapping Monticello etc.
If everyone uses, or has the option of using the same tools for building images, in every release, then this facilitates exchange of packages among forks, and helps those of us who are not at liberty to jump ship on a whim, and it helps those who do want to jump ship on a whim.
I was asking you for months to think along these lines and make such strategic choices based upon contributing to things that the squeak communities have in common or might want to use in common...
The vision for Installer was to be a base for building derived images in all release images in all forks. The vision for MC1.5 was to be a set of tools that actually worked to load code in all images in all forks. The vision for LevelPlayingField is to provide bootstrapping for difficult code to load in all images in all forks. The vision for Sake/Packages was to be a universal set of package definitions and dependencies that show what works where in ALL images, in ALL Forks. The vision for SUnit-improved was to be a universal means for defining SUnit and SSpec tests for ALL images so that it is possible to indicate what works where, in ALL forks, so that packages of tests can be maintained in common for ALL forks.
So, may I appeal to you, please contribute to and use installer, rather than compete with it, and perhaps reconsider your approach to the other ideas listed above.
Keith
p.s. I am considering, recruiting members for an independant "guild" of package developers, whose role would be to promote interoperability between squeak forks, so that packages can be developed once and deployed anywhere. I think this is needed because now we have no core image developers in either squeak or pharo, that look at interoperability.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I always thought that you guys didnt actually understand installer.
Which is partly your own fault.
How so? I may have been lax at many things, but on leaving Installer unexplained, I cant see that charge sticking. 1 - Installer was documented from the beginning, on the swiki, and in the class comment 2 - the first line of the documentation states that it is a DSL for installing things 3 - the second line of the documentation talks about executing scripts in the workspace. 4 - Installer has been available and used by many people for 3 years - Pharo are the only people routinely misusing it as far as I know. I have talked about having a strategic pan-fork approach until I am blue in the face, to the point of exhaustion. What I am left with is some mysterious unanswered questions. Like why hasn't my arm been bitten off for this stuff, and how does anyone actually get anything done with Universes? Keith
I've posted a blog entry (based on the class-comment of the Gofer class) to get people started. http://www.lukas-renggli.ch/blog/gofer Lukas 2009/9/19 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>:
What is the difference in:
goals? implementation? speed? license? other aspects?
I can see that they both can install packages in a pharo image.
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
El lun, 21-09-2009 a las 13:46 +0200, Lukas Renggli escribió:
I've posted a blog entry (based on the class-comment of the Gofer class) to get people started.
http://www.lukas-renggli.ch/blog/gofer
Lukas
From the post:
Now the following expressions can be used at any time: gofer load Load all packages. gofer update Update all packages. gofer merge Merge all packages into their working copies. gofer diff Display the difference between the working copy and the base version of all packages. gofer commit Commit all modified packages. gofer revert Revert all packages to their base version. gofer recompile Recompile all packages. gofer unload Unload all packages. This is something that I can't understand. Is this supposed to be a package management system per se, a la Metacello, aptitude, yum?? Isn't just a installer of MC packages but tries to manage the MC database of packages in a way that is clean and *atomic*? So, there will be a registry of gofer installed operations so that can be utilized after the install operation (maybe months later)? Or will just be for trying to install some group of packages and if some error happens immediatly revert? Can you relate the scenarios showing how gofer is intended to use, because until now (maybe my narrow perspective) the examples shown can be done also with ScriptLoader and Installer. Other thing, I tried to convert my image install script but I can't finish because I install packages from monticello configurations (magma 1.0r42) and from my local directory repository. Neither of those options can be handled by gofer (as far as I can see). Of course this can be corrected, it is just to integrate the correct MC installer classes. That reminds me other thing, Installer can handle monticello configurations, is the corresponding way of loading the packages using gofer to list each package in the mcm file in a gofer script? So mcm will not used or it is just that there have no been time to add those capability to gofer? Thanks -- Miguel Cobá http://miguel.leugim.com.mx
This is something that I can't understand. Is this supposed to be a package management system per se, a la Metacello, aptitude, yum?? Isn't just a installer of MC packages but tries to manage the MC database of packages in a way that is clean and *atomic*?
No, as it says on the first line, it is a tool to perform basic Monticello operations on multiple packages. It is based on scripts that we wrote to handle the 70+ Seaside 3.0 packages, as well as code we wrote for Flair, a system that has similar goals than Metacello, but is now discontinued in favor of Metacello. Maybe Metacello will use Gofer as its loader.
So, there will be a registry of gofer installed operations so that can be utilized after the install operation (maybe months later)?
No. Unless you store them somewhere. The class-side of Gofer has some examples for common set of packages.
Or will just be for trying to install some group of packages and if some error happens immediatly revert?
No. It uses the normal tools available through Monticello, but provides a convenient interface. Furthermore it runs some additional code to keep the image in a clean state. For example it ensures that every working copy has an repository assigned, that repositories pointing to the same physical location are of the same instance, that unused repositories get removed again, that categories are properly ordered, that unload operations do not leave empty categories and protocols, etc.
Can you relate the scenarios showing how gofer is intended to use, because until now (maybe my narrow perspective) the examples shown can be done also with ScriptLoader and Installer.
Maybe the loading part can be performed by these tools (but then again they mess up with the repositories), but not really the other operations.
Other thing, I tried to convert my image install script but I can't finish because I install packages from monticello configurations (magma 1.0r42) and from my local directory repository. Neither of those options can be handled by gofer (as far as I can see). Of course this can be corrected, it is just to integrate the correct MC installer classes.
Gofer is designed for Monticello only.
That reminds me other thing, Installer can handle monticello configurations, is the corresponding way of loading the packages using gofer to list each package in the mcm file in a gofer script? So mcm will not used or it is just that there have no been time to add those capability to gofer?
Yeah, a Gofer specification is very similar to a Monticello Configuration. In fact when you use specific versions it is basically the same, but then again it messes up with the repositories and categories, something that drives me mad for years already :-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
El lun, 21-09-2009 a las 18:04 +0200, Lukas Renggli escribió:
This is something that I can't understand. Is this supposed to be a package management system per se, a la Metacello, aptitude, yum?? Isn't just a installer of MC packages but tries to manage the MC database of packages in a way that is clean and *atomic*?
No, as it says on the first line, it is a tool to perform basic Monticello operations on multiple packages. It is based on scripts that we wrote to handle the 70+ Seaside 3.0 packages, as well as code we wrote for Flair, a system that has similar goals than Metacello, but is now discontinued in favor of Metacello. Maybe Metacello will use Gofer as its loader.
ok.
So, there will be a registry of gofer installed operations so that can be utilized after the install operation (maybe months later)?
No. Unless you store them somewhere. The class-side of Gofer has some examples for common set of packages.
Or will just be for trying to install some group of packages and if some error happens immediatly revert?
No. It uses the normal tools available through Monticello, but provides a convenient interface. Furthermore it runs some additional code to keep the image in a clean state. For example it ensures that every working copy has an repository assigned, that repositories pointing to the same physical location are of the same instance, that unused repositories get removed again, that categories are properly ordered, that unload operations do not leave empty categories and protocols, etc.
I always tough that monticello have complete control over the packages installed and unloaded from an image. I also assumed that it cleaned its mess after each operation. It is good to know this. But, a question, shouldn't this be part of Monticello. Or monticello fixed so to not leave dirty images behind it. Well that is just a comment. I know that there are alread a dozen monticello versions. :)
Can you relate the scenarios showing how gofer is intended to use, because until now (maybe my narrow perspective) the examples shown can be done also with ScriptLoader and Installer.
Maybe the loading part can be performed by these tools (but then again they mess up with the repositories), but not really the other operations.
Other thing, I tried to convert my image install script but I can't finish because I install packages from monticello configurations (magma 1.0r42) and from my local directory repository. Neither of those options can be handled by gofer (as far as I can see). Of course this can be corrected, it is just to integrate the correct MC installer classes.
Gofer is designed for Monticello only.
ok.
That reminds me other thing, Installer can handle monticello configurations, is the corresponding way of loading the packages using gofer to list each package in the mcm file in a gofer script? So mcm will not used or it is just that there have no been time to add those capability to gofer?
Yeah, a Gofer specification is very similar to a Monticello Configuration. In fact when you use specific versions it is basically the same, but then again it messes up with the repositories and categories, something that drives me mad for years already :-)
Cheers, Lukas
Thanks -- Miguel Cobá http://miguel.leugim.com.mx
Or will just be for trying to install some group of packages and if some error happens immediatly revert?
No. It uses the normal tools available through Monticello, but provides a convenient interface. Furthermore it runs some additional code to keep the image in a clean state. For example it ensures that every working copy has an repository assigned, that repositories pointing to the same physical location are of the same instance, that unused repositories get removed again, that categories are properly ordered, that unload operations do not leave empty categories and protocols, etc.
I always tough that monticello have complete control over the packages installed and unloaded from an image. I also assumed that it cleaned its mess after each operation. It is good to know this. But, a question, shouldn't this be part of Monticello. Or monticello fixed so to not leave dirty images behind it. Well that is just a comment. I know that there are alread a dozen monticello versions. :)
This is not only the fault of Monticello. Some of the problems (duplicated or missing repositories, wrongly ordered categories) only arise when you want to load multiple packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Can you relate the scenarios showing how gofer is intended to use,
because until now (maybe my narrow perspective) the examples shown can be done also with ScriptLoader and Installer.
Maybe the loading part can be performed by these tools (but then again they mess up with the repositories), but not really the other operations.
ScriptLoader is not for public consumption. It is a private class full of crap that we slowly built to sustain our process. I would like slowly move some of the behavior - loadOneAfterTheOther: - loadSilently - mark ; changedPackages either to Gofer or to use gofer to perform certain actions.
participants (6)
-
Igor Stasenko -
keith -
Lukas Renggli -
Miguel Enrique Cobá Martinez -
Schwab,Wilhelm K -
Stéphane Ducasse