Grrr, even the mailing list changes, the first match in gmail just bounces, ;)
---------- Forwarded message ---------- From: Nicolas Cellier <[hidden email]> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <[hidden email]>, The general-purpose Squeak developers list <[hidden email]> Hi, I must come back to one of the balkanization and lack of stability that most upset me.http://www.squeaksource.com/ How can the Metacello feature of supporting cross-dialect work if the dialect specific configuration of dependencies are scattered all around the web? Do the CPAN or PyPI have to change their URL each time a new release of perl or python is released? Careless decisions in this area can easily sabotage the cross-dialect initiative. Maybe I'm ranting by ignorance. I wish your answers will reassure me. Nicolas |
> On 10 Mar 2017, at 00:21, Nicolas Cellier <[hidden email]> wrote: > > Grrr, even the mailing list changes, the first match in gmail just bounces, ;) > > ---------- Forwarded message ---------- > From: Nicolas Cellier <[hidden email]> > Date: 2017-03-10 0:05 GMT+01:00 > Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? > To: Pharo Development <[hidden email]>, The general-purpose Squeak developers list <[hidden email]> > > > Hi, > I must come back to one of the balkanization and lack of stability that most upset me. > > Imagine that you are developping a cross dialect library, say for Squeak/Pharo and why not Gemstone. > > Imagine that this library has a few dependencies to some other libraries, either Core like Alien/FFI or more exotic third party also available in other dialects. > > The question are: > -1) where are you supposed to maintain your own ConfigurationOf*? Just next to your original source code. It is your config and you maintain it. > -2) where are you supposed to find the ConfigurationOf* dependencies? Anywhere ;-) The config refers to its home repo. That is the one you should use in your dependency. The different repos Pharo uses are for classification purposes. That is how I understand it anyway. > Once upon a time, the answer would have been > http://www.squeaksource.com/MetacelloRepository > > But now, what is it? I see surprisingly few updates here (apart from Sven and a few others). > > How can the Metacello feature of supporting cross-dialect work if the dialect specific configuration of dependencies are scattered all around the web? > > Do the CPAN or PyPI have to change their URL each time a new release of perl or python is released? > > Careless decisions in this area can easily sabotage the cross-dialect initiative. > > Maybe I'm ranting by ignorance. > I wish your answers will reassure me. > > Nicolas > |
2017-03-10 8:51 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:
Yes, I generally maintain the ConfigurationOf* in my own repo along with the other packages, and I copy the ConfigurationOf* to some centralized place (http://www.squeaksource.com/ It's like registering the application i nSqueakMap/CPAN/PyPI/etc... > -2) where are you supposed to find the ConfigurationOf* dependencies? The config refers to its home repo. That is the one you should use in your dependency. OK, that's not particularly robust if source code repository is moving (i.e. on squeaksource, then ss3, then smalltalkhub, then github via filetree, then ...) A centralized Configuration provides a level of resilience.
Otherwise, ConfigurationOf* scattered around the web are not discoverable. The fact that there are as many repos as pharo versions is because there is no such easy thing as filtering the ConfigurationOf* matching target version without loading them all... Thanks Sven for answering. Nicolas
|
> On 10 Mar 2017, at 12:27, Nicolas Cellier <[hidden email]> wrote: > > > > 2017-03-10 8:51 GMT+01:00 Sven Van Caekenberghe <[hidden email]>: > > > On 10 Mar 2017, at 00:21, Nicolas Cellier <[hidden email]> wrote: > > > > Grrr, even the mailing list changes, the first match in gmail just bounces, ;) > > > > ---------- Forwarded message ---------- > > From: Nicolas Cellier <[hidden email]> > > Date: 2017-03-10 0:05 GMT+01:00 > > Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? > > To: Pharo Development <[hidden email]>, The general-purpose Squeak developers list <[hidden email]> > > > > > > Hi, > > I must come back to one of the balkanization and lack of stability that most upset me. > > > > Imagine that you are developping a cross dialect library, say for Squeak/Pharo and why not Gemstone. > > > > Imagine that this library has a few dependencies to some other libraries, either Core like Alien/FFI or more exotic third party also available in other dialects. > > > > The question are: > > -1) where are you supposed to maintain your own ConfigurationOf*? > > Just next to your original source code. It is your config and you maintain it. > > > Yes, I generally maintain the ConfigurationOf* in my own repo along with the other packages, > and I copy the ConfigurationOf* to some centralized place (http://www.squeaksource.com/MetacelloRepository) > It's like registering the application i nSqueakMap/CPAN/PyPI/etc... > > > > -2) where are you supposed to find the ConfigurationOf* dependencies? > > Anywhere ;-) > > The config refers to its home repo. That is the one you should use in your dependency. > > OK, that's not particularly robust if source code repository is moving > (i.e. on squeaksource, then ss3, then smalltalkhub, then github via filetree, then ...) > > A centralized Configuration provides a level of resilience. > > > The different repos Pharo uses are for classification purposes. > > That is how I understand it anyway. > > > No. The Pharos repos exist because we NEED something like a catalog (SqueakMap/CPAN/PyPI/whatever). > Otherwise, ConfigurationOf* scattered around the web are not discoverable. > > The fact that there are as many repos as pharo versions is because there is no such easy thing as filtering the ConfigurationOf* matching target version without loading them all... > > Thanks Sven for answering. > BTW, why do you continue to put copies in http://www.squeaksource.com/MetacelloRepository One single repo to rule them all is also a single point of failure, right ? As I understand it, the catalog (code/browser) searches backwards from its own version specific repo to all previous ones to the 'old' one you mention. Like I said, putting a config in a version specific repo means that you (or whoever makes the copy) acknowledge that you support that version or at least that it works there. It is a very soft, very simple mechanism. In the Pharo world, the catalog is the main entry point to easily loading stuff. But there is so much going on that that is certainly not the only way, nor is it possible to enforce just one way. There are teams that copy all source code repos and their configs to their own source code control systems to fix versions and to maintain absolute control and independence. YMMV. > Nicolas > > > Once upon a time, the answer would have been > > http://www.squeaksource.com/MetacelloRepository > > > > But now, what is it? I see surprisingly few updates here (apart from Sven and a few others). > > > > How can the Metacello feature of supporting cross-dialect work if the dialect specific configuration of dependencies are scattered all around the web? > > > > Do the CPAN or PyPI have to change their URL each time a new release of perl or python is released? > > > > Careless decisions in this area can easily sabotage the cross-dialect initiative. > > > > Maybe I'm ranting by ignorance. > > I wish your answers will reassure me. > > > > Nicolas > > |
If you are looking for central repository, then Pharo Catalog is the closest thing to that.
You copy your ConfigurationOf to the appropriate MetaRepoForPharo{40/50/60}. The ConfigurationOf can be just a copy of your actual ConfOf, or something that loads the actual one --- e.g. with Git you typically don't have ConfigurationOf, but BaselineOf (which doesn't contain any version information), and from the Catalog ones you just load this baseline. But considering git is only now gaining bigger traction it is in a flummox. Peter On Fri, Mar 10, 2017 at 01:04:59PM +0100, Sven Van Caekenberghe wrote: > > > On 10 Mar 2017, at 12:27, Nicolas Cellier <[hidden email]> wrote: > > > > > > > > 2017-03-10 8:51 GMT+01:00 Sven Van Caekenberghe <[hidden email]>: > > > > > On 10 Mar 2017, at 00:21, Nicolas Cellier <[hidden email]> wrote: > > > > > > Grrr, even the mailing list changes, the first match in gmail just bounces, ;) > > > > > > ---------- Forwarded message ---------- > > > From: Nicolas Cellier <[hidden email]> > > > Date: 2017-03-10 0:05 GMT+01:00 > > > Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? > > > To: Pharo Development <[hidden email]>, The general-purpose Squeak developers list <[hidden email]> > > > > > > > > > Hi, > > > I must come back to one of the balkanization and lack of stability that most upset me. > > > > > > Imagine that you are developping a cross dialect library, say for Squeak/Pharo and why not Gemstone. > > > > > > Imagine that this library has a few dependencies to some other libraries, either Core like Alien/FFI or more exotic third party also available in other dialects. > > > > > > The question are: > > > -1) where are you supposed to maintain your own ConfigurationOf*? > > > > Just next to your original source code. It is your config and you maintain it. > > > > > > Yes, I generally maintain the ConfigurationOf* in my own repo along with the other packages, > > and I copy the ConfigurationOf* to some centralized place (http://www.squeaksource.com/MetacelloRepository) > > It's like registering the application i nSqueakMap/CPAN/PyPI/etc... > > > > > > > -2) where are you supposed to find the ConfigurationOf* dependencies? > > > > Anywhere ;-) > > > > The config refers to its home repo. That is the one you should use in your dependency. > > > > OK, that's not particularly robust if source code repository is moving > > (i.e. on squeaksource, then ss3, then smalltalkhub, then github via filetree, then ...) > > > > A centralized Configuration provides a level of resilience. > > > > > > The different repos Pharo uses are for classification purposes. > > > > That is how I understand it anyway. > > > > > > No. The Pharos repos exist because we NEED something like a catalog (SqueakMap/CPAN/PyPI/whatever). > > Otherwise, ConfigurationOf* scattered around the web are not discoverable. > > > > The fact that there are as many repos as pharo versions is because there is no such easy thing as filtering the ConfigurationOf* matching target version without loading them all... > > > > Thanks Sven for answering. > > BTW, why do you continue to put copies in http://www.squeaksource.com/MetacelloRepository > > One single repo to rule them all is also a single point of failure, right ? > > As I understand it, the catalog (code/browser) searches backwards from its own version specific repo to all previous ones to the 'old' one you mention. > > Like I said, putting a config in a version specific repo means that you (or whoever makes the copy) acknowledge that you support that version or at least that it works there. It is a very soft, very simple mechanism. > > In the Pharo world, the catalog is the main entry point to easily loading stuff. But there is so much going on that that is certainly not the only way, nor is it possible to enforce just one way. There are teams that copy all source code repos and their configs to their own source code control systems to fix versions and to maintain absolute control and independence. YMMV. > > > Nicolas > > > > > Once upon a time, the answer would have been > > > http://www.squeaksource.com/MetacelloRepository > > > > > > But now, what is it? I see surprisingly few updates here (apart from Sven and a few others). > > > > > > How can the Metacello feature of supporting cross-dialect work if the dialect specific configuration of dependencies are scattered all around the web? > > > > > > Do the CPAN or PyPI have to change their URL each time a new release of perl or python is released? > > > > > > Careless decisions in this area can easily sabotage the cross-dialect initiative. > > > > > > Maybe I'm ranting by ignorance. > > > I wish your answers will reassure me. > > > > > > Nicolas > > > > > |
In reply to this post by Nicolas Cellier
Nicolas Since a couple of years already we have one MetaRepo per version MCSmalltalkhubRepository
owner: 'Pharo'
project: 'MetaRepoForPharo60'
user: 'StephaneDucasse'
password: '' MCSmalltalkhubRepository
owner: 'Pharo'
project: 'MetaRepoForPharo50'
user: 'StephaneDucasse'
password: '' MCSmalltalkhubRepository
owner: 'Pharo'
project: 'MetaRepoForPharo40'
user: 'StephaneDucasse'
password: '' MCSmalltalkhubRepository
owner: 'Pharo'
project: 'MetaRepoForPharo30'
user: 'StephaneDucasse'
password: '' You see it is in place since Pharo 30 :). We are working on a single place (web site) to publish packages but also the package metadata. The problem right now is that we cannot verify/publish a configuration without loading it. The idea is to have kind of distributions of packages working and validated vs. a folder full of possible packages I hated so much the squeak catalog because 5 times on 6 nothing worked. Stef
|
On Sat, Mar 11, 2017 at 1:34 AM, stepharong <[hidden email]> wrote:
> Nicolas > Since a couple of years already we have one MetaRepo per version > > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo60' > user: 'StephaneDucasse' password: '' > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo50' > user: 'StephaneDucasse' password: '' > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo40' > user: 'StephaneDucasse' password: '' > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo30' > user: 'StephaneDucasse' password: '' > > You see it is in place since Pharo 30 :). > > We are working on a single place (web site) to publish packages but also the > package metadata. > The problem right now is that we cannot verify/publish a configuration > without loading it. > > The idea is to have kind of distributions of packages working and validated > vs. a folder full of possible packages > I hated so much the squeak catalog because 5 times on 6 nothing worked. > > Stef Just a thought for when the catalog validation is implemented, it would be good to report what the test coverage is, so this can be filtered on to distinguish from projects that are green just because they have a single test. Also, (as time permits) it would be good to have a checkbox to filter out projects having no description, and be enabled by default. cheers -ben |
On Sat, Mar 11, 2017 at 09:12:55PM +0800, Ben Coman wrote:
> On Sat, Mar 11, 2017 at 1:34 AM, stepharong <[hidden email]> wrote: > > Nicolas > > Since a couple of years already we have one MetaRepo per version > > > > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo60' > > user: 'StephaneDucasse' password: '' > > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo50' > > user: 'StephaneDucasse' password: '' > > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo40' > > user: 'StephaneDucasse' password: '' > > MCSmalltalkhubRepository owner: 'Pharo' project: 'MetaRepoForPharo30' > > user: 'StephaneDucasse' password: '' > > > > You see it is in place since Pharo 30 :). > > > > We are working on a single place (web site) to publish packages but also the > > package metadata. > > The problem right now is that we cannot verify/publish a configuration > > without loading it. > > > > The idea is to have kind of distributions of packages working and validated > > vs. a folder full of possible packages > > I hated so much the squeak catalog because 5 times on 6 nothing worked. > > > > Stef > > Just a thought for when the catalog validation is implemented, > it would be good to report what the test coverage is, > so this can be filtered on to distinguish from projects > that are green just because they have a single test. > > Also, (as time permits) > it would be good to have a checkbox to filter out projects > having no description, and be enabled by default. There is no sane reason why description should be empty, so please just make it mandatory (and author/contact too (and possibly tags)). Re coverage: that would require that the user installing it actually understands how the metric was computed... e.g. call coverage != path coverage; also the usefulness and complexity of coverage will greatly depend on the used task. You can get 100% call coverage with some algo lib, but good luck getting there with UI. Likewise if the project is more diverse you can very easily skew it. Peter |
Free forum by Nabble | Edit this page |