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.

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 <[hidden email]> wrote:

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

On May 22, 2014, at 5:00 AM, Christophe Demarey <[hidden email]> 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.

+ 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