Versionner: Specifying un-configured packages as dependencies
Hi all, Iâm using Versionner to make a ConfigurationOf and things are working quite well (thanks for that!) until I want to add the Roassal2Spec package as a dependency. The dialog box only shows packages with a configuration, and Roassal2Spec does not have one. Itâs just one package. How can I add this guy to my configuration? Thanks in advance, ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi, Le 20 mai 2014 à 15:01, Johan Fabry a écrit :
Hi all,
Iâm using Versionner to make a ConfigurationOf and things are working quite well (thanks for that!) until I want to add the Roassal2Spec package as a dependency. The dialog box only shows packages with a configuration, and Roassal2Spec does not have one. Itâs just one package. How can I add this guy to my configuration?
The only way (and not recommended) to add it with Versionner would be to add it as a package of your project but it will not work as it is hosted on another repository. Why not adding a new config for this project (in your project repository) or, better, in the roassal repository?
Christophe Demarey wrote
but it will not work as it is hosted on another repository
Not that I'm recommending it, but if necessary, you could always copy it into your project's repo to get around that (or I think you can specify a repository in the #with: block of the package spec. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Specifying-un-configured-packages-as-depend... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Le 20 mai 2014 à 22:53, Sean P. DeNigris a écrit :
Christophe Demarey wrote
but it will not work as it is hosted on another repository
Not that I'm recommending it, but if necessary, you could always copy it into your project's repo to get around that (or I think you can specify a repository in the #with: block of the package spec.
To me, it is preferable to add a configuration (even if very small) for each dependency outside your project. It is the way it should be done (that's why Versionner only allows that) but they are always other ways or workarounds.
On May 21, 2014, at 5:07 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Le 20 mai 2014 à 22:53, Sean P. DeNigris a écrit :
Christophe Demarey wrote
but it will not work as it is hosted on another repository
Not that I'm recommending it, but if necessary, you could always copy it into your project's repo to get around that (or I think you can specify a repository in the #with: block of the package spec.
To me, it is preferable to add a configuration (even if very small) for each dependency outside your project. It is the way it should be done (that's why Versionner only allows that) but they are always other ways or workarounds.
Thanks for the answers, my trick now was to ask Alex to include the required package inside the configuration of Roassal. :-) In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Le 22 mai 2014 à 01:02, Johan Fabry a écrit :
On May 21, 2014, at 5:07 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
To me, it is preferable to add a configuration (even if very small) for each dependency outside your project. It is the way it should be done (that's why Versionner only allows that) but they are always other ways or workarounds.
Thanks for the answers, my trick now was to ask Alex to include the required package inside the configuration of Roassal. :-)
In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me.
The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example: for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell. That's why I'm really in favor of having configurations, even for one single MC package inside the configuration. * I mean, not a Monticello package but a piece of software that you want to deliver independently. It may be a whole project or part of it. It may also refers to one or many Monticello packages
On May 22, 2014, at 5:00 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me.
The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example: ⢠for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem ⢠... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell. That's why I'm really in favor of having configurations, even for one single MC package inside the configuration.
I understand what you are saying, but my point of view is different. I put a high priority on the simplicity rule: if it is just one package with no special dependencies the Monticello package is the simplest solution, so you use that. If there are special dependencies, then the simplest solution for that package to work is to have a configuration for it, so you create it. The latter is still not so obvious apparently, Alex has tried 2 times to include Roassal2Spec in the Roassal config, and it still does not load in a default Pharo 3. Alex, can you try again? ( hint hint :-) ) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
jfabry wrote
I put a high priority on the simplicity rule
It's good to know the dangers, but for single packages with no dependencies, I often just add it to my project. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Specifying-un-configured-packages-as-depend... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
+ 100
The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example:
* for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem * ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell.
That's why I'm really in favor of having configurations, even for one single MC package inside the configuration.
* I mean, not a Monticello package but a piece of software that you want to deliver independently. It may be a whole project or part of it. It may also refers to one or many Monticello packages
I think I'm now at the same point... I need to add Zinc-SSO as a dependency. Should I create a configuration for it? Where should it be stored? thanks On Thu, May 22, 2014 at 1:55 PM, stepharo <stepharo@free.fr> wrote:
+ 100
The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example:
- for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem - ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell.
That's why I'm really in favor of having configurations, even for one single MC package inside the configuration.
* I mean, not a Monticello package but a piece of software that you want to deliver independently. It may be a whole project or part of it. It may also refers to one or many Monticello packages
Sorry, SSO is a Group in ConfigurationOfZincHTTPComponent. I got confused as I didn't know about groups. Please ignore my previous email, I just need to make my project depend on Zinc SSO group On Sat, May 24, 2014 at 10:58 PM, Arturo Zambrano <arturo.zambrano@gmail.com
wrote:
I think I'm now at the same point... I need to add Zinc-SSO as a dependency. Should I create a configuration for it? Where should it be stored?
thanks
On Thu, May 22, 2014 at 1:55 PM, stepharo <stepharo@free.fr> wrote:
+ 100
The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example:
- for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem - ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell.
That's why I'm really in favor of having configurations, even for one single MC package inside the configuration.
* I mean, not a Monticello package but a piece of software that you want to deliver independently. It may be a whole project or part of it. It may also refers to one or many Monticello packages
participants (5)
-
Arturo Zambrano -
Christophe Demarey -
Johan Fabry -
Sean P. DeNigris -
stepharo