Fwd: Where are the Metacello ConfigurationOfYourProject supposed to be?
Grrr, even the mailing list changes, the first match in gmail just bounces, ;) ---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project@lists.gforge.inria.fr>, The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> 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*? -2) where are you supposed to find the ConfigurationOf* dependencies? 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
On 10 Mar 2017, at 00:21, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Grrr, even the mailing list changes, the first match in gmail just bounces, ;)
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project@lists.gforge.inria.fr>, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
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 <sven@stfx.eu>:
On 10 Mar 2017, at 00:21, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
Grrr, even the mailing list changes, the first match in gmail just bounces, ;)
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project@lists.gforge.inria.fr>, The general-purpose Squeak developers list <squeak-dev@lists. squeakfoundation.org>
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 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
On 10 Mar 2017, at 12:27, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-03-10 8:51 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 10 Mar 2017, at 00:21, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Grrr, even the mailing list changes, the first match in gmail just bounces, ;)
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project@lists.gforge.inria.fr>, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
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 <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-03-10 8:51 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 10 Mar 2017, at 00:21, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Grrr, even the mailing list changes, the first match in gmail just bounces, ;)
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project@lists.gforge.inria.fr>, The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
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
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 <stepharong@free.fr> 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 <stepharong@free.fr> 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
participants (5)
-
Ben Coman -
Nicolas Cellier -
Peter Uhnak -
stepharong -
Sven Van Caekenberghe