Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[stepharong]

On Mon, 13 Feb 2017 12:28:11 +0100, Peter Uhnák  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.


we could too. :)



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?

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  
 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  
 wrote:



Peter,



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.





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/Seaside3.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/Pharo/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
















--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

On 02/13/2017 03:28 AM, Peter Uhnák 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.



You are correct that the MetaRepo could accomplish this using a 
ConfigurationOf (the current scheme basically does follow this model), 
but this is a bit of a hack ..


A better solution is to use a "project specification object" --- many 
other languages use their own flavor of "project specification object" 
to define the versions.


Having project specification objects means that a whole host of project 
meta data can be included in the object as first class objects without 
having to hack around with adding methods (by convention) to a 
ConfigurationOf




> 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.
I don't agree that this would be needlessly complex ... the 
implementation I use with tODE leverages gh-pages on github and STON ... 
having first class objects for project specifications, means that tools 
can be built to work directly with these objects, instead of loading a 
ConfigurationOf and hoping that the expected meta data is there ...


Dale

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Peter Uhnak]

> 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.

Git takes care of the versioning, so the Baseline is really just a baseline, 
like it would be in a ConfigurationOf.

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Ben Coman]

On Mon, Feb 13, 2017 at 7:28 PM, Peter Uhnák  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,

 

 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.
>>>

 

>>>
>>> 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
>
>


>>>
>>>
>>
>>
>

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Peter Uhnák]

> 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?

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,
>>>
>>> 
>>>
>>> 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.
>>
>>>
>>> 
>>>
>>
>> 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


>>>
>>>
>>
>>
>
>

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

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 
 wrote:



Peter,



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.





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/Seaside3.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/Pharo/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

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[stepharong]

On Sun, 12 Feb 2017 16:36:42 +0100, Dale Henrichs  
 wrote:



Peter,



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.





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/Seaside3.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/Pharo/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







--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Ben Coman]

On Sun, Feb 12, 2017 at 11:36 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Peter,
>
> 
>
> 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.
>
> ConfigurationOf should really be phased out -- they've been obsolete for
> 3-4 years now... BaselineOf is preferred.
>

Does BaselineOf work with Monticello?
I thought it was only for use with git.

cheers -ben


>
> 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).
>
> 
>
> Dale
>
> [1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.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
>>
>>
>
>

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Dale Henrichs]

Peter,



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.


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).




Dale

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.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/Pharo/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

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[stepharong]

Hi,

would it make sense to take configurations from metarepos instead  
directly from the source?


I do not think so but if people show me otherwise I could follow that.
Usually I have a conf in my repo referencing other repo and not the meta  
one

Then I push in the meta just to config.



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/Pharo/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




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

[Stephan Eggermont]

On 12/02/17 13:03, Peter Uhnak wrote:

would it make sense to take configurations from metarepos instead directly from 
the source?


Not really. They are not kept exactly up-to-date in practice, and having 
one for each Pharo version is also kind of a bad practice.
What is missing is some pushing mechanism that makes sure that 
configurations from the source repo get promoted to the metarepo when 
they pass some ci (smoke) tests.


Stephan

[Pharo-users] Depending on MetaRepo instead of the target repo

[Peter Uhnak]

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/Pharo/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