It could be easily done, but in a ugly way to me. The only thing you know about 
a configuration package is that its name begins with 'ConfigurationOf', or it 
has some specific methods. There is no data above a package to know if it is a 
regular one or a configuration. Am I wrong ? If there is, it can be done in a 
better way.

Franck

From: [email protected]
Date: Mon, 17 Aug 2015 09:04:09 +0000
To: [email protected]
Subject: Re: [Pharo-dev] Projects are slowly getting to live... and

impressive you guys are busy non stop, I am feel so glad Pharo move forward so 
fast. 

No I did not mean to remove configurations but rather hide them, or group them 
together so they dont display together with other packages. 

On Mon, Aug 17, 2015 at 12:01 AM stepharo <[email protected]> wrote:

  
    
  
  
    First it could be worse :) We cannot build a full ecosystem without
    capturing dependencies. 

    

    Second we are (christophe) working since a year on the Cargo Package
    Manager. 

    [Christophe knows many package manager (Java ruby and others).]

    With Cargo every single package expresses its dependencies instead
    of using external packages such as a Configuration.

    So we will see how it goes.

    

    Stef

    

    
      
      
        One of the things that annoy me is how many Configurations
          and Baselines pollute the package space that are of little
          interest to the user. It would be nice to group them and
          filter them out of Nautilus unless user asks for them. 

          

        
        I really like this new approach great work. 

      
      

      
        On Sun, Aug 16, 2015 at 7:34 PM stepharo <[email protected]>
          wrote:

        
        

          

          Le 16/8/15 17:00, Sean P. DeNigris a écrit :

          > stepharo wrote

          >> you get a project (group) with all your packages
          together ready to work ;)

          > Cool! I feel more and more that the standard "Package"
          pane is only useful

          > for... packaging, and when one takes off the dependency
          management hat and

          > puts the user hat on (i.e. most of the time), what you
          really want there is

          > a logical view of the system. So I see three use cases:

          > - Logical view of the system - I guess this was the
          original intention of

          > Categories, but has been hijacked by Monticello

          > - By project - which, as you just showed, we have now,
          yay!

          > - By package - the least useful, but primary (up til
          now), view

          

          Indeed.

          We will see what we get at the end but may be something like

          

               MyProject

               AnotherProject

               System

               LowLevel

          

          And people will not be overwhelmed by hundreds of nice
          packages. :)

          

          I think that touching package contents under the assumption
          that the

          package list is too long in the UI

          is the wrong way to look at the problem.

               Packages are unit of deployment and we need Projects -
          unit of

          knowledge. And the UI should shows both

               depending on the view we want to get.

          

          Stef

          >

          >

          >

          > -----

          > Cheers,

          > Sean

          > --

          > View this message in context: 
http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p4843286.html

          > Sent from the Pharo Smalltalk Developers mailing list
          archive at Nabble.com.

          >

          >

          >

          

          

        
      
    
    

                                          

Reply via email to