[Pharo-project] [MC] Adding a constraint when declaring a required package
Maybe we should forbid a package XXX-YYY to be required for a package named XXX What do you think? A simple check will do it... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alex I imagine that this is to avoid mistake like Moose Moose-X Moose-Y and that people do it Moose-All Moose-X Moose-Y If this is what you have in mind how would it work from a process point of view 1- I create Moose 2- I create Moose-XXX -> wanring 3- remove/rename Moose -> Moose-All then be able to create Moose-XXX This scenario would be realllllly important because we can really screw up MC packges with overlapping packages Scenario 2 1 - I have Moose 2- I load Moose-XXX PS: if you want to have feedback from people, they should not know what you are implying in advance like me. On Oct 11, 2008, at 12:19 PM, Alexandre Bergel wrote:
Maybe we should forbid a package XXX-YYY to be required for a package named XXX What do you think? A simple check will do it...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Let me put it in another way. Is there a situation where a package named MyPackage should require another package MyPackage-Foo. As we experienced, this evil dependency brings inconsistencies when saving MyPackage. What would it a nice way to prevent such situation ?
I imagine that this is to avoid mistake like Moose Moose-X Moose-Y
and that people do it Moose-All Moose-X Moose-Y
Even these situations are not clean. We should have MooseAll MooseX MooseY I do not see a reason to have a - within the name. If you have 3 class categories: Moose Moose-X Moose-Y It means that the package Moose contains Moose-X and Moose-Y definitions In Visualworks there is no dash convention, which is much better... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion: We documented the package naming conventions for Seaside 2.9 here: http://code.google.com/p/seaside/wiki/PackageNaming The complete list of packages is documented here: http://code.google.com/p/seaside/wiki/LoadOrder When following these conventions there are no conflicts. The dashes are there to separate the different concerns of the name. We don't use meta-packages (-All), because every developer has a different set of packages anyway. Cheers, Lukas
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
It makes sense. But in that setting, creating a package named 'Seaside' and beginning to add some Seaside-... packages as required would be disastrous. No? But maybe I am missing something here... Cheers, Alexandre On 12 Oct 2008, at 11:46, Lukas Renggli wrote:
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion:
We documented the package naming conventions for Seaside 2.9 here:
http://code.google.com/p/seaside/wiki/PackageNaming
The complete list of packages is documented here:
http://code.google.com/p/seaside/wiki/LoadOrder
When following these conventions there are no conflicts. The dashes are there to separate the different concerns of the name. We don't use meta-packages (-All), because every developer has a different set of packages anyway.
Cheers, Lukas
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
The problem is that you cannot forbid that now. Or do you? what is the impact of forbidden that now on existing code? Stef On Oct 12, 2008, at 11:19 AM, Alexandre Bergel wrote:
Let me put it in another way. Is there a situation where a package named MyPackage should require another package MyPackage-Foo. As we experienced, this evil dependency brings inconsistencies when saving MyPackage.
What would it a nice way to prevent such situation ?
I imagine that this is to avoid mistake like Moose Moose-X Moose-Y
and that people do it Moose-All Moose-X Moose-Y
Even these situations are not clean. We should have MooseAll MooseX MooseY
I do not see a reason to have a - within the name.
this is just a character as any other. So I would not do anything special with it.
If you have 3 class categories: Moose Moose-X Moose-Y
It means that the package Moose contains Moose-X and Moose-Y definitions
In Visualworks there is no dash convention, which is much better...
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test. stef On Oct 12, 2008, at 11:46 AM, Lukas Renggli wrote:
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion:
We documented the package naming conventions for Seaside 2.9 here:
http://code.google.com/p/seaside/wiki/PackageNaming
The complete list of packages is documented here:
http://code.google.com/p/seaside/wiki/LoadOrder
When following these conventions there are no conflicts. The dashes are there to separate the different concerns of the name. We don't use meta-packages (-All), because every developer has a different set of packages anyway.
Cheers, Lukas
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 10/12/08, Alexandre Bergel <alexandre@bergel.eu> wrote:
It makes sense. But in that setting, creating a package named 'Seaside' and beginning to add some Seaside-... packages as required would be disastrous. No? But maybe I am missing something here...
Sure, but a package named 'Seaside' does not follow the conventions. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 10/12/08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test.
Tests are always in separate package (so that you don't have to load them in productive code). As you can see in the list, most packages have an associated test package: Seaside-Session and Seaside-Tests-Session You find a more complicated example of a group of packages that also includes platform specific code at the bottom of <http://code.google.com/p/seaside/wiki/PackageNaming>. Cheers, Lukas
stef
On Oct 12, 2008, at 11:46 AM, Lukas Renggli wrote:
In Visualworks there is no dash convention, which is much better...
This might be interesting in the context of discussion:
We documented the package naming conventions for Seaside 2.9 here:
http://code.google.com/p/seaside/wiki/PackageNaming
The complete list of packages is documented here:
http://code.google.com/p/seaside/wiki/LoadOrder
When following these conventions there are no conflicts. The dashes are there to separate the different concerns of the name. We don't use meta-packages (-All), because every developer has a different set of packages anyway.
Cheers, Lukas
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Stéphane Ducasse wrote:
I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test.
stef Traditional PackageInfo users are expected to use the standard implementation or roll their own, for each package that needs a custom definition.
MC1.5+ Comes with a version of PackageInfo that has the notion of package types. Predefined package types that you can make use of through a simple dot suffix package name. So Package developers can pick from a list of predetermined package types which should cover most existing use cases. For example, you could have different packaging of a package for different platforms, i.e. Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin Thus rolling your own package definition, is no longer intended for defining just one package, but rather a class of packages. Example: Monticello.impl (implementation) Monticello.test (tests) Are two such package names, which are automatically managed by subclasses of PackageInfo The PackageInfoImpl class excludes test categories, while the PackageInfoTests class includes them. ====== testCategoryMatches ^ #('*-Tests-*' '*-Tests') ====== This is so that your tests can live alongside your implementation, without cluttering up the images with Test categories at the top level. So if you want to manage the Tests together with the Implementation, add a package named 'Monticello', this will include all of the classes. If you want to publish the implementation only, then add a package named 'Monticello.impl' etc etc... Keith
MC1.5+ Comes with a version of PackageInfo that has the notion of package types. Predefined package types that you can make use of through a simple dot suffix package name.
Dot suffixes are traditionally used for branches. We use them extensively in Seaside. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Keith the problems with such approaches is that each of these nice little extensions will break the analysis tools we are developing. I would prefer a good and stable solution over everybody can hack its own. I want some invariants on top of which we can build other tools. Stef On Oct 12, 2008, at 10:12 PM, Keith Hodges wrote:
Stéphane Ducasse wrote:
I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test.
stef Traditional PackageInfo users are expected to use the standard implementation or roll their own, for each package that needs a custom definition.
MC1.5+ Comes with a version of PackageInfo that has the notion of package types. Predefined package types that you can make use of through a simple dot suffix package name.
So Package developers can pick from a list of predetermined package types which should cover most existing use cases. For example, you could have different packaging of a package for different platforms, i.e. Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin
Thus rolling your own package definition, is no longer intended for defining just one package, but rather a class of packages.
Example:
Monticello.impl (implementation) Monticello.test (tests)
Are two such package names, which are automatically managed by subclasses of PackageInfo
The PackageInfoImpl class excludes test categories, while the PackageInfoTests class includes them.
====== testCategoryMatches
^ #('*-Tests-*' '*-Tests') ======
This is so that your tests can live alongside your implementation, without cluttering up the images with Test categories at the top level.
So if you want to manage the Tests together with the Implementation, add a package named 'Monticello', this will include all of the classes. If you want to publish the implementation only, then add a package named 'Monticello.impl' etc etc...
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe, one easy step to make MC simpler, is to remove (sub)categories in packages. In that case, two packages, 'Moose' and 'Moose-Test' will be completely unrelated. Cheers, Alexandre On 12 Oct 2008, at 22:20, Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each of these nice little extensions will break the analysis tools we are developing. I would prefer a good and stable solution over everybody can hack its own. I want some invariants on top of which we can build other tools.
Stef
On Oct 12, 2008, at 10:12 PM, Keith Hodges wrote:
Stéphane Ducasse wrote:
I lukas I see that you group together all the tests and I would prefer to have test associate with the package they test.
stef Traditional PackageInfo users are expected to use the standard implementation or roll their own, for each package that needs a custom definition.
MC1.5+ Comes with a version of PackageInfo that has the notion of package types. Predefined package types that you can make use of through a simple dot suffix package name.
So Package developers can pick from a list of predetermined package types which should cover most existing use cases. For example, you could have different packaging of a package for different platforms, i.e. Seaside.squeak vs Seaside.vw Seaside.gs vs Seaside.dolphin
Thus rolling your own package definition, is no longer intended for defining just one package, but rather a class of packages.
Example:
Monticello.impl (implementation) Monticello.test (tests)
Are two such package names, which are automatically managed by subclasses of PackageInfo
The PackageInfoImpl class excludes test categories, while the PackageInfoTests class includes them.
====== testCategoryMatches
^ #('*-Tests-*' '*-Tests') ======
This is so that your tests can live alongside your implementation, without cluttering up the images with Test categories at the top level.
So if you want to manage the Tests together with the Implementation, add a package named 'Monticello', this will include all of the classes. If you want to publish the implementation only, then add a package named 'Monticello.impl' etc etc...
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Lukas Renggli wrote:
MC1.5+ Comes with a version of PackageInfo that has the notion of package types. Predefined package types that you can make use of through a simple dot suffix package name.
Dot suffixes are traditionally used for branches. We use them extensively in Seaside.
Lukas
I dont think you do, are you telling me that he package Seaside2.8a1 has a branch called ".8a1" Keith
Stéphane Ducasse wrote:
Keith
the problems with such approaches is that each of these nice little extensions will break the analysis tools we are developing. I would prefer a good and stable solution over everybody can hack its own. I want some invariants on top of which we can build other tools.
Stef That is entirely the point. When people roll their own, you end up with endless variations. (i.e. no stable situation)
This at least attempts to capture and codify the use-cases that people have. Since PackageInfo is in charge of what is and is not in a package then your "tools" have to query package info anyway. Keith
Dot suffixes are traditionally used for branches. We use them extensively in Seaside.
I dont think you do, are you telling me that he package Seaside2.8a1 has a branch called ".8a1"
Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch. There are smaller examples in the 2.9 repository. For example you have these 3 branches of the core package Seaside-Core: Seaside-Core-pmm.configcleanup.53.mcz, Seaside-Core-jf.cache.3.mcz, Seaside-Core-jf.painter.10.mcz. The first two have been merged at some point, the latter one has been dropp-. The original Monticello UI once grouped and sorted these branches nicely. Somebody broke that a long time ago. Another problem is that some people decided to use a dot within their initials, that 'breaks' it too ;-) Out of the 40 000 versions on SqueakSource there are almost 2 000 versions that use named branching (200 without Seaside). Furthermore, I know many commercial projects that use named branches as part of their development/release cycles. So it is certainly not some feature that you can just ignore when changing Monticello. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Oct 13, 2008, at 7:51 AM, Lukas Renggli wrote:
Dot suffixes are traditionally used for branches. We use them extensively in Seaside.
I dont think you do, are you telling me that he package Seaside2.8a1 has a branch called ".8a1"
Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch.
There are smaller examples in the 2.9 repository. For example you have these 3 branches of the core package Seaside-Core: Seaside-Core-pmm.configcleanup.53.mcz, Seaside-Core-jf.cache.3.mcz, Seaside-Core-jf.painter.10.mcz. The first two have been merged at some point, the latter one has been dropp-.
The original Monticello UI once grouped and sorted these branches nicely. Somebody broke that a long time ago. Another problem is that some people decided to use a dot within their initials, that 'breaks' it too ;-)
Yeah. I know the guy :) Now it would be good to settle down and have one way to do things. So I'm eager to hear concrete proposals :)
Out of the 40 000 versions on SqueakSource there are almost 2 000 versions that use named branching (200 without Seaside). Furthermore, I know many commercial projects that use named branches as part of their development/release cycles. So it is certainly not some feature that you can just ignore when changing Monticello.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
On Oct 13, 2008, at 7:51 AM, Lukas Renggli wrote:
Dot suffixes are traditionally used for branches. We use them extensively in Seaside.
I dont think you do, are you telling me that he package Seaside2.8a1 has a branch called ".8a1"
Yes, that's the 2.8 branch. Up to 2.8 every version had its own branch.
In MC1.5 we took the step of formally defining the naming syntax, with tests. So that it would be able to reliably work out which is which, in order to reduce ambiguities. I.e. in order to settle down. Anyhow, MC1.5 fully supports the idea that packages may have different versions and that the may be named MyPackage3.0.4 etc As for concrete proposals, it works, and it doesnt break the use of "so called" branching. Keith
participants (5)
-
Alexandre Bergel -
Alexandre Bergel -
Keith Hodges -
Lukas Renggli -
Stéphane Ducasse