Monticello requiring network access to save a package in a local repository?
Hello, Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access. Why is it so? I was working without network access and this bite me. I was able to get out of trouble with my Phone as an access point. But for some scenarios (w/ security and no external network access) this is really a pain. Also, the fact that I had to do a Cmd-. to get out of this is annyoying. Clues? Phil
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases. We once thought about making this check optional (and a setting). One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried. On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares) the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :) Esteban On Oct 3, 2013, at 6:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban
On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
Beware, I got bitten recently on Squeak-trunk and I have overriden an existing package by publishing twice with same name... This is because the Squeak version does silently ignore if there was a previous version in the package-cache. And because source.squeak.org just accepts to override... 2013/10/3 Esteban Lorenzano <estebanlm@gmail.com>
yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares)
the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :)
Esteban
On Oct 3, 2013, at 6:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban
On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
That cannot happen on smalltalkhub. duplicated version names are not accepted. There are 16 projects on source.squeak.org, that should have a low probability to happen again... On 2013-10-03, at 19:46, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Beware, I got bitten recently on Squeak-trunk and I have overriden an existing package by publishing twice with same name... This is because the Squeak version does silently ignore if there was a previous version in the package-cache. And because source.squeak.org just accepts to override...
2013/10/3 Esteban Lorenzano <estebanlm@gmail.com>
yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares)
the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :)
Esteban
On Oct 3, 2013, at 6:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban
On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
I for sure can. So, this is gone in 3.0 and if I do the "magic trick" you showed us during the Hangout, all we be fine, right? --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Oct 3, 2013 at 7:22 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares)
the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :)
Esteban
On Oct 3, 2013, at 6:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban
On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
yep :) you could transform the hack into a nice preference, you know... I would be happy to integrate that :) Esteban ps: for those who doesn't know it, I showed Phil how I cheat Pharo3 to load Pharo2 configurations, which is... just to override #metacelloPlatformAttributes :) That way I can easily test packages from Ph2 into Ph3 (Btw, so far, everything I tested works, with the unique exception of FFI/Alien). Then we thought that a preference "threat this image as compatible with Pharo2" would be cool, to easy the migration of packages :) On Oct 3, 2013, at 8:12 PM, phil@highoctane.be wrote:
I for sure can.
So, this is gone in 3.0 and if I do the "magic trick" you showed us during the Hangout, all we be fine, right?
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Thu, Oct 3, 2013 at 7:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: yes. Also the name repetition is a) very improbably anyway and 2) nobody cares (or at lease, MC does not cares)
the only problem that could happen is in the remote case where you could want to join repositories previously separated. We think we can live with that potential problem :)
Esteban
On Oct 3, 2013, at 6:32 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We were fed up about that and we made sure that we can work off line (and not checking all the repositories on earth) in 3.0 with esteban
On Oct 3, 2013, at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, that is what Monticello does on a save: check for potential name conflicts in all linked repositories. It is just the way it is. It is not a 100% foolproof way to guarantee uniqueness, but it will help in certain cases.
We once thought about making this check optional (and a setting).
One way out might be to remove all but the package-cache from the repositories linked to your package, but I haven't tried.
On 03 Oct 2013, at 15:58, "phil@highoctane.be" <phil@highoctane.be> wrote:
Hello,
Monticello goes fetching a unique number in the previous version of a given package on Smallatkhub and that means requiring network access.
Why is it so?
I was working without network access and this bite me.
I was able to get out of trouble with my Phone as an access point.
But for some scenarios (w/ security and no external network access) this is really a pain.
Also, the fact that I had to do a Cmd-. to get out of this is annyoying.
Clues?
Phil
Here is the preference for doing just that: http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/Settings-Meta... In fact, I noticed there was no Settings-Metacello and I created one, along with that single pref in it. Maybe will be useful for future things The metacelloPlatformAttributes has been changed like this and put in a *settings-metacello protocol instead of being in "miscellaneous". metacelloPlatformAttributes "Returns the tags for the conditional platform loading in Metacello. Pay attention the order is important: from most to least general." "For release integrators, we should not have #'pharo1.3x' **and** #'pharo1.4.x'" ^ SmalltalkImage Pharo2Compatible ifTrue: [ #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') ] ifFalse: [ #(#squeakCommon #pharo #'pharo3.x' #'pharo3.0.x') ] . Feel free to integrate :-) Phil
participants (6)
-
Camillo Bruni -
Esteban Lorenzano -
Nicolas Cellier -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe