Automatically adding http repository, username and password in MetacelloBrowser

>  3. The older algorithms in MetacelloBrowser were pretty cavalier
>     about creating MCPackage instances and subsequently creating
>     MCWorkingCopies for package that weren't installed in the image (I
>     mentioned this problem in mail yesterday). In the case where these
>     were actually _new_ packages I suppose that was a good thing, but
>     it was creating empty MCWorkingCopy images for packages that
>     existed, but were not (yet) loaded in the image - in the old
>     MetacelloBrowser, load a configuration for a project that is _not_
>     already in your image and then browse around in that
>     configuration... then take a look at the MetacelloBrowser and you
>     will see that an empty workingCopy is created for each of the
>     packages referenced by the configuration ... this is not good at
>     all and leads to all sorts of weird problems.

>> This wasn't a mistake. I changed the methods, because they were
>> annoying the heck out of me:)
>
> Arg... That was one reason why I created the browser :-)
>
>> 1. The algorithm that was used wasn't correct .. in my case at
>> least, I already had a repository associated with the package and
>> it was prompting me for credentials to a repository that was not
>> even the correct repository....and it was very insistent about
>> it:)
>
> Did you had an http repository associated to the Monticello
> Repository? Normally, the metacello browser tries to find one. If it
> does not, then it propose one.

>
>> 2. There is already a "standard way" for saving a package in
>> Metacello and I think that it is important that the Metacello be
>> consistent on this point. If there's a problem with how save
>> package works, the changes should be consistent whether you are
>> using the MetacelloBrowser or the MetacelloToolBox to do the
>> saving.
>
> Yes, but the standard way is not optimal for me. I load the
> configuration with the 'load configuration' button. Without opening
> the monticello browser therefore. I have one single login and
> password for _all_ my projects and commit. Wouldn't it be nice if the
> browser remember it?

>
>> 3. The older algorithms in MetacelloBrowser were pretty cavalier
>> about creating MCPackage instances and subsequently creating
>> MCWorkingCopies for package that weren't installed in the image (I
>> mentioned this problem in mail yesterday). In the case where these
>> were actually _new_ packages I suppose that was a good thing, but
>> it was creating empty MCWorkingCopy images for packages that
>> existed, but were not (yet) loaded in the image - in the old
>> MetacelloBrowser, load a configuration for a project that is _not_
>> already in your image and then browse around in that
>> configuration... then take a look at the MetacelloBrowser and you
>> will see that an empty workingCopy is created for each of the
>> packages referenced by the configuration ... this is not good at
>> all and leads to all sorts of weird problems.
>
> Oh...
>
>> When I finished "fixing the problems" those methods were no longer
>> used so I removed them along with a number of other methods that
>> were no longer used.
>>
>> I have nothing against the methods themselves, they just need to be
>> used under the correct circumstances.
>
> Yes, this is what we are trying to find out.
>
>
>> I can imagine use cases where they might be useful (during intitial
>> project creation for example), where a repository needs to be
>> associated with the new configuration, but the old implementation
>> was too aggressive in a) creating packages when it shouldn't have
>> and b) thinking that a repository needed to be associated with a
>> package when it didn't.
>
> Do you use other repository than an HTTP one?

>
> On 02/25/2011 12:41 PM, Alexandre Bergel wrote:
>>> This wasn't a mistake. I changed the methods, because they were
>>> annoying the heck out of me:)
>>
>> Arg... That was one reason why I created the browser :-)
>>
>>> 1. The algorithm that was used wasn't correct .. in my case at
>>> least, I already had a repository associated with the package and
>>> it was prompting me for credentials to a repository that was not
>>> even the correct repository....and it was very insistent about
>>> it:)
>>
>> Did you had an http repository associated to the Monticello
>> Repository? Normally, the metacello browser tries to find one. If it
>> does not, then it propose one.
>
> I am using http repositories so I'm not sure why I was being asked to supply a repository when there was already a perfectly good repository associated with the package ... I actually ignored this problem until I fixed the issue mentioned in item 3 below and several others and by then I was using the save packages from MetacelloToolBox so could not easily reproduce the issue.
>
>>
>>> 2. There is already a "standard way" for saving a package in
>>> Metacello and I think that it is important that the Metacello be
>>> consistent on this point. If there's a problem with how save
>>> package works, the changes should be consistent whether you are
>>> using the MetacelloBrowser or the MetacelloToolBox to do the
>>> saving.
>>
>> Yes, but the standard way is not optimal for me. I load the
>> configuration with the 'load configuration' button. Without opening
>> the monticello browser therefore. I have one single login and
>> password for _all_ my projects and commit. Wouldn't it be nice if the
>> browser remember it?
>
> Certainly, remembering the username and password will be useful. I have no problem adding things back in to support new functionality ... but I took them out because the reason for them being there in the first place disappered ... I'm glad that I deleted them so we could have this conversation and be explicit about the rationale for what I did, rather than "silently orphan the useful functionality":)
>
>>
>>> 3. The older algorithms in MetacelloBrowser were pretty cavalier
>>> about creating MCPackage instances and subsequently creating
>>> MCWorkingCopies for package that weren't installed in the image (I
>>> mentioned this problem in mail yesterday). In the case where these
>>> were actually _new_ packages I suppose that was a good thing, but
>>> it was creating empty MCWorkingCopy images for packages that
>>> existed, but were not (yet) loaded in the image - in the old
>>> MetacelloBrowser, load a configuration for a project that is _not_
>>> already in your image and then browse around in that
>>> configuration... then take a look at the MetacelloBrowser and you
>>> will see that an empty workingCopy is created for each of the
>>> packages referenced by the configuration ... this is not good at
>>> all and leads to all sorts of weird problems.
>>
>> Oh...
>>
>>> When I finished "fixing the problems" those methods were no longer
>>> used so I removed them along with a number of other methods that
>>> were no longer used.
>>>
>>> I have nothing against the methods themselves, they just need to be
>>> used under the correct circumstances.
>>
>> Yes, this is what we are trying to find out.
>>
>>
>>> I can imagine use cases where they might be useful (during intitial
>>> project creation for example), where a repository needs to be
>>> associated with the new configuration, but the old implementation
>>> was too aggressive in a) creating packages when it shouldn't have
>>> and b) thinking that a repository needed to be associated with a
>>> package when it didn't.
>>
>> Do you use other repository than an HTTP one?
>
> I do use directory-based repositories.
>
>>
>>>
>>> Sooo, I think we should address the missing use cases and approach
>>> them slightly differently...perhaps prompt for a repository when
>>> creating the initial configuration itself ...
>>
>> Is there a way to get the repository for a given configuration?
>
> Take a look at ConfigurationInfo>>workingCopy ... where we get the workingCopy of the configuration class ... from the workingCopy you can get the repositories via the repositoryGroup...
>
> BTW, I look at your changes and it is the logic in #repositoryOfPackageNamed: where things fall down ... there is also an assumption about where the repository is located ... my work involves repositories located in places other than squeaksource ... so there really are a number of issues with that algorithm ...
>
> the intent is good, don't get me wrong, but the actual logic is wrong for me case ... I was hitting the `repositories ifEmpty` every single time and had a dozen questions to answer before hitting a walk back since it was picking the wrong repository ...
>>
>>> BTW, I've added a "Product" category to the bug tracker so that
>>> MetacelloBrowser bugs can be submitted to the metacello issue
>>> tracker (change Product-Core to Product-Browser)...
>>
>>
>> Cool cool!
>
> Dale
>