On Mon, Feb 13, 2017 at 7:28 PM, Peter Uhnák <i.uh...@gmail.com> wrote:

> > I do not think so but if people show me otherwise I could follow that.
>
> Well, in most languages (their package dependencies) one can just specify
> name of the project and a version. The location/how to load it is pulled
> from a central repository.
> So that's why I thought that maybe the MetaRepo could be used in a similar
> fashion.
>
> > In the long term the the MetaRepo should be replaced by a repository of
> project specification objects
>
> That also seems needlessly complex; basically just ConfigurationOf
> separated to parts. I do not want to restrict the users, but with a central
> repo the most common use case shouldn't be 10 lines of configuration.
>
>
> > Does BaselineOf work with Monticello?
> > I thought it was only for use with git.
>
> Monticello or Metacello?
>

I meant, can a Baseline be stored in / operate from a mcz file, without a
Configuration?
I thought git made Baselines feasible since git takes care of versioning.

cheers -ben


> You can download/install projects just fine (and also depend on other
> baselines from your baselines or configurations)
>
> Metacello new
>     baseline: 'FileDialog';
>     repository: 'github://peteruhnak/file-dialog/repository';
>     load.
>
> Also BaselineOf is just a subclass of ConfigurationOf.
>
>
>
> On Mon, Feb 13, 2017 at 2:48 AM, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>> Very good to hear ... I have to try to be a bit more patient :)
>>
>>
>>
>> On 2/12/17 9:37 AM, stepharong wrote:
>>
>>> On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs <
>>> dale.henri...@gemtalksystems.com> wrote:
>>>
>>> Peter,
>>>>
>>>> <wishful thinking>
>>>>
>>>> In the long term the the MetaRepo should be replaced by a repository of
>>>> project specification objects (like this [1]). Each project specification
>>>> would contain the meta data for a project (like this[2]) instead of a copy
>>>> of a ConfigurationOf that is almost always out-of-date.
>>>>
>>>
>>> Yes we are working on it.
>>> Now 64bits, FFI, Iceberg, bootstrap got our attention.
>>>
>>>>
>>>> ConfigurationOf should really be phased out -- they've been obsolete
>>>> for 3-4 years now... BaselineOf is preferred.
>>>>
>>>> If folks are using something like git/github, with proper branching,
>>>> then a BaselineOf wouldn't be published on the master branch until the unit
>>>> tests are passing (travis-ci).
>>>>
>>>
>>> I want more than just the tests but this is a start.
>>>
>>>>
>>>> </wishful thinking>
>>>>
>>>
>>> We will arrive there. Because I want it too.
>>> Now pavel worked on the bootstrap to avoid to lose all the energy that
>>> guille put on it.
>>>
>>>
>>>> Dale
>>>>
>>>> [1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
>>>> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seas
>>>> ide3.ston
>>>> On 2/12/17 4:03 AM, Peter Uhnak wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> would it make sense to take configurations from metarepos instead
>>>>> directly from the source?
>>>>>
>>>>> And more imporantly: would be considered bad practice for users to do
>>>>> it right now?
>>>>>
>>>>> E.g.
>>>>>
>>>>> spec
>>>>>     project: 'Magritte'
>>>>>     with: [ spec
>>>>>         className: #ConfigurationOfMagritte3;
>>>>>         versionString: #stable;
>>>>>         repository: 'http://smalltalkhub.com/mc/Ph
>>>>> aro/MetaRepoForPharo50/main/' ].
>>>>>
>>>>> v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/'
>>>>>
>>>>>
>>>>> pros:
>>>>> * the (e.g. Magritte) developer can freely change platforms
>>>>> * the ConfigurationOf could differ between various MetaRepo versions
>>>>> (combined with git it could reduce their complexity)
>>>>> * users do not have to think about where is the canonical repo (I've
>>>>> seen project that had copies on SS, STHub, GitHub, and a custom location
>>>>> -_-)
>>>>>
>>>>> cons:
>>>>> * the ConfigurationOf could differ between various MetaRepo versions
>>>>> (if the code is compatible, then two repos have to be updated
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

Reply via email to