Is RPackage dead?

Hi guys

so what do we do with RPackage
        - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off.
        but this means that we will stay with the old browsers. Sounds like a promising future.
        - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done.
        - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose
        a real plan to get towards a solution.
       
Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement.
Now without help it will not work (if you do not put energy on the table).  I have a lot of wishes too and something else to do too.
Because we have categories in addition… I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this
means that we will have to match the complete system with subcategories (
        Graphics-Core
        should match Graphics*

So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete
discussions. Apparently nobody care anyway. So this should not be important after all.

Stef

On Oct 28, 2011, at 1:20 PM, Stéphane Ducasse wrote:


Cool ...

Ben

In 2008 I wrote:

   There is a clean 1:1 mapping between categories/protocols and
   packages. If X is the package name, then ...

   1. Category X is the core-package.
   2. Category X-y is a sub-package y.
   3. Protocol *X are extension methods.
   4. Protocol *X-y is an extension to the y protocol.

   I see this as a way to move from the naming conventions to a first
   class package model. It is critical to have a browser that hides those
   naming conventions, while still keeping them (at the moment) for
   backward compatibility.

Since there is no clean migration path, I vote for (A).

When looking at Pharo today I don't see the current packaging system
(or the lack thereof) as a major problem. The current infrastructure
works reasonably well and does not hinder progress. What is really
painful is that everything breaks with every release. Thus, what would
be way more important is a module/namespace system so that we can load
and run different versions of the same code without interfering. In
the current state Pharo 1.3 is a dead end, because I will never be
able to load my code into Pharo 1.4.

Lukas

On 28 October 2011 14:40, Benjamin <[hidden email]> wrote:


--
Lukas Renggli
www.lukas-renggli.ch

Hi,

B.

Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following:

Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.

Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations.

Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories.


So, why should this not work?

Btw, there is a working basic GlamorousClassicCoder using RPackage. I did not announce it yet because there are still details to deal with.

Cheers,
Doru


On 28 Oct 2011, at 13:20, Stéphane Ducasse wrote:

--
www.tudorgirba.com

"Every successful trip needs a suitable vehicle."

> Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following:
>
> Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.

If this works like this then that would be perfect, but I had a
different impression from the mail ("yes people will have to change
the configurations" and "does not tell me that this is easy but
propose a real plan to get towards a solution"). To make RPackage
usable there is the need to have both ways work simultaneously and
transparently together for some time. Similar to how this was done
with the transition of underscore assignments ...

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Hi,

On 28 Oct 2011, at 21:30, Lukas Renggli wrote:

For all practical purposes, every change in the base system is reflected in RPackage. This was the point of the SystemAnnouncement. What does not work yet is the mechanism of having modifications at the level of RPackage reflected in categories. There are two ways around this:
1. Have tools take care to only affect categories and not RPackage directly, and only read from RPackage.
2. Build an intermediary support for this sole purpose.

I think both are doable. Perhaps we can start from 1. and generalize a layer for 2.

Cheers,
Doru



> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

--
www.tudorgirba.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

Le 28/10/2011 14:55, Lukas Renggli a écrit :
>
> Since there is no clean migration path, I vote for (A).
>
> When looking at Pharo today I don't see the current packaging system
> (or the lack thereof) as a major problem. The current infrastructure
> works reasonably well and does not hinder progress. What is really
> painful is that everything breaks with every release.
I vote for B.

But could'nt we adopt an Ubuntu like release scheme:
- Decide that 1.3 is a Long Term Supported version: it means critical
bogue fixes only, it stays LTS until another release is declared as LTS.
- 1.4 and subsequent releases would be testing releases (RPackage in 1.4).

Cheers
Alain

I do not buy your analysis at all.
Look at the state of package organizer and other.

Then I do not see why 1.3 is a dead-end. In any case thank for the positive feedback.

Stef

On Oct 28, 2011, at 2:55 PM, Lukas Renggli wrote:

Hi doru

I will spend amos time to do an analysis of the possible paths.
Right now RPackage Organizer is fill up based on PackageOrganizer so a category is mapped to a package and extensions are managed well (probably some funky case still do not work 100%).

Now what marcus and igor were afraid is that big packages with a lot of subcategories would become a lot of packages.
Examples:
        Morphic
                -> Morphic-Menu, Morphic-Basic, Morphic….

To me this is not a problem but I introduced at the level of packages the possibility to tag classes:
This way we could take MCWorkingCopies as package (but with the fucking matching that nobody understand really) and the large packages
could be displayed in browser
        Package Morphic
                Morphic-menu
                        classes
                Morphic-Basic
                        classes
        …

Now I do not like that because it means that we will have to do all the matching i.e. *Morphic-Menu methods belong to Morphic because there is Morphic and not Morphic-Menu
as packages.



> B.
>
> Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following:
>
> Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.

yes we have already that. Probably with some bugs with the matching in edge cases.


> Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations.

Yes this is what afraid marcus and igor because people will cry that they have to change the configurations and that they will lose the subcategory.

For me I want to get rid of categories this is a bogus concept #cat #Cat 'Cat' 'cat' string bad management and pattern matching as well as the monolithic systemOrganizer is terrible.

>
> Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories.
>
>
> So, why should this not work?

Cries: "oh my nice package now is split in multiple ones….. kind of problems"

> Btw, there is a working basic GlamorousClassicCoder using RPackage. I did not announce it yet because there are still details to deal with.


Nautilus is fully working on RPackage too.
:)


So I will continue to see what I can do.
To me I would simplify everything. We have too many concepts. I would love to remove category and have packages.
We have a good implementation of packages.

Stephane, as i said before, i do not see problems with RPackage / naming.
These things are orthogonal, as to me.
We can keep naming scheme as we use today, but switch to RPackage.

A package can keep the list of category names and that's it. They
could even be completely different, if people want it.
Say, package is named
Foo
and contain categories:
'Foo-Core'
'Bar'

The rationale is simple:
it is up to human(s) to decide what a package should contain, and what
names to use. Let's just embrace the imperfection and do not dictate
people
how they should name their categories in order to make sure that
classes in that categories will be put into concrete package.
If people like to confuse themselves with category names, not matching
the package name , it should be their own choice and responsibility.

--
Best regards,
Igor Stasenko.

I will check and take some notes to see what should be done so that we can remove package info and packageOrganizer and use instead Rpackage and RpackageOrganizer.
It means that I will have to implement the matching semantics because monticello will ask to classes their categories via package info.
RPackage is not related to categories so this is the problem.
And to me this makes the system more complex.

Stef

I agree now this is the path to arrive there that is important to me.

Stef

On Oct 30, 2011, at 3:23 PM, Igor Stasenko wrote:

Hi,

Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.

Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.

So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package.

It's a smooth transition that can be spread over a longer period of time.

Cheers,
Doru



On 30 Oct 2011, at 15:29, Stéphane Ducasse wrote:

--
www.tudorgirba.com

"Reasonable is what we are accustomed with."

On 30 October 2011 23:05, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.
>
> Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
>

I think you looking at this at wrong angle.
People can create a mess with any software, no matter what good it is.
If you deny people from doing the mess within the package , you are
not solving the problem - you just shifting it into another plane - a
package management.
So you forcing people to do the mess at package management level. Fine :)
But personally, I fail to see why mess with package management
(dependencies, load order etc) is better than single bloated package
with lots of categories.

Because, imposing any strict naming rules is like trying to swim against stream.
If i want a _single_ package with two categories, like:
 - core
 - utils

give me a strong reason why i can't have it, and why i have to waste
my time with package management, if all i need is single package?




--
Best regards,
Igor Stasenko.

Hi,

On 30 Oct 2011, at 22:43, Igor Stasenko wrote:

> On 30 October 2011 23:05, Tudor Girba <[hidden email]> wrote:
>> Hi,
>>
>> Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.
>>
>> Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
>>
> I think you looking at this at wrong angle.

I strongly disagree :).

> People can create a mess with any software, no matter what good it is.

Sure. But, the thing is that just because mess is possible, you do not want to make it easy.

So now I think you are looking at the problem in a strange way. You seem to argue that we should optimize the system around toy examples. Almost anything meaningful requires more than that. Let's optimize around what matters.

And regarding wasting time, you will waste much less than now at the moment when Monticello will become transparent as well. In other words, you will simply stay in your code browser and load and publish from there. No mess, no fuss. But to get there easily, we need this 1-to-1 between what is publishable and what is in the image.

Perhaps where you will need some attention is loading order, but when Metacello will get a better integration, many things will be possible. But, we need a stable and simple base.

Cheers,
Doru

--
www.tudorgirba.com

"What we can governs what we wish."

> Hi,
>
> Wait. The RPackage should not hold more than one category. That is the whole point. If you will allow mapping more than one category to an RPackage, we will either never get rid of categories or we will enter into the messy territory of nested packages. At this time, we certainly do not want the former, and we cannot afford the later.

The problem is that we are all talking about different things.
        - RPackage is fully working: it does not need any category. RPackage is a list of class + a list of method (nicely optimized to be queried efficienly).
          RPackage is equivalent to MCPackage when MCPackages are limited to top level categories (i.e. Foo and *foo).
       
        - Now we have MCPackage and they are overlapping multiple categories and this is the mess. Because they cross multiple PackageInfo and….


> Please, let's keep it simple. There is no point allowing people to create mess by default. There is no practical use case for having this extra stuff. In fact, we know from experience that if we want to manage a larger than trivial system, we need strict conventions. Anything else pretty much fails in the long run.
>
> So, I come back to my point. At this point, we can safely load RPackage in the image (actually, in the Moose image, it is always loaded) and have tools be built on top of them. Then in Pharo 1.5 or later we start transitioning by not allowing people to commit more than one Category/RPackage in a Monticello package.

I agree now marcus is afraid that it will generate too many packages. For me I would like to have a simple model.

>>
>> give me a strong reason why i can't have it, and why i have to waste
>> my time with package management, if all i need is single package?
>
> So now I think you are looking at the problem in a strange way. You seem to argue that we should optimize the system around toy examples. Almost anything meaningful requires more than that. Let's optimize around what matters.
>
> And regarding wasting time, you will waste much less than now at the moment when Monticello will become transparent as well. In other words, you will simply stay in your code browser and load and publish from there. No mess, no fuss. But to get there easily, we need this 1-to-1 between what is publishable and what is in the image.

Yes I would like to simply see packages in any browser.
I agree with that :)

And igor I added tags to packages:
so any class of a package can be associated with any number of tags.

so tools can display

        Package
                Tag1
                        ClassA
                        Class B
                Tag2
                        Class A (yes)
                        Class C
       
but this tagging has nothing to do with package identification.

> Perhaps where you will need some attention is loading order, but when Metacello will get a better integration, many things will be possible. But, we need a stable and simple base.

Doru I think that I will continue like we got it.
I will work on making sure that we can remove PackageInfo in 1.5 (i.e. controlling the logic and moving it inside, deprecating as much as possible from the interface)
same for PackageOrganizer.

Syeg