Probably Metacello sucks…
Locked
12
12
 
|
Hi,
this is an observation on usage of Metacello. I guess that metacello is too complicated to be used. For example I was using the `jenkins` version of Woden configuration, but now it’s broken. And when you look at the Woden repo[1] it says that the way to load it is: Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) project version: '3.0') load. Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) loadBleedingEdge. Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge Maybe instead of depending on the configuration of Woden, and saying that to load my project, people should just use a stable version of my configuration, I should copy the script from Woden repo, add some more lines to load the other projects I depend on and ask people to run a half page script in order to use my tools? What do you think? it looks like an easier solution. Uko |
|
|
Hi, How?
I do not understand your problem. I know that jb produced a new configuration for Woden. And it should work. Every project should have a configuration. Stef |
|
|
But it doesn’t ;). The script loads everything, while the configuration says: "Error: Name not found: WithOpenGLAndExamples”.
But it should be a responsibility of the owner, not JB…
|
|
|
On 31/05/2015 13:34, Yuriy Tymchuk
wrote:
It's not broken it's just a bug related to configuration present by default in the image, you have to unload the oswindow configuration first... MCPackageLoader unloadPackage: (MCPackage named: 'ConfigurationOfOSWindow')
|
Re: Probably Metacello sucks…
|
|
In reply to this post by Uko2
It is not going to get much easier than Metacello.
Referring to #stable should probably stop, at least for configurations that are being developed or use dependencies that are being developed. And we need better tool support for groups. Configuration Management is never going to be easy. The Woden script looks broken, it depends on a numbered version of a dependency. Stable version of NBOpenGL is 3.1, not 3.0 That depends on version 3.0 of NBXLib NBXLib defines no symbolic versions OSWindow stable refers to NBXLib-Core-RonieSalgado.13 that doesn't exist in PharoExtras/NBOpenGL Looks like a good moment to draw some dependency diagrams Stephan |
|
|
Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that?
Uko > On 31 May 2015, at 19:42, Stephan Eggermont <[hidden email]> wrote: > > It is not going to get much easier than Metacello. > Referring to #stable should probably stop, at least for > configurations that are being developed or use > dependencies that are being developed. > And we need better tool support for groups. > Configuration Management is never going to be easy. > > The Woden script looks broken, it depends on a > numbered version of a dependency. > > Stable version of NBOpenGL is 3.1, not 3.0 > That depends on version 3.0 of NBXLib > NBXLib defines no symbolic versions > OSWindow stable refers to NBXLib-Core-RonieSalgado.13 that doesn't > exist in PharoExtras/NBOpenGL > > Looks like a good moment to draw some dependency diagrams > > Stephan > > |
|
|
Le 11 juin 2015 à 07:52, Yuriy Tymchuk a écrit : > Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? http://smalltalkhub.com/#!/~PharoExtras/Tool-DependencyAnalyser But take care, it only spots static dependencies (inheritance, reference, extensions, traits). |
smime.p7s (5K)
Re: Probably Metacello sucks…
|
|
In reply to this post by Uko2
On 11/06/15 07:52, Yuriy Tymchuk wrote:
> Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? What I've done is get all latest versions out of smalltalkhub and collect the signatures that are used. That can provide upper and lower limits of possible versions. Stephan |
|
|
Absence of Metacello won't help you dealing with dependencies and loading stuff by using hand-made scripts by dozens of peopleIt may be too complicated to use, especially at earlier stages of development, and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge). But always staying on bleeding edge hurts a lot (that's why it called so) and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there. -- Best regards,
Igor Stasenko. |
|
|
dependency management for projects is *never* an easy task.
who think that the complex on loading project X or Y is because of metacello simply does not understand the inherent complexity the task it tries to solve has. things can be improved, yes… but no matter what tools we create, this will just make a bit easier what is complex. now… I think one of our problems is the use of #stable into configurations. I have expressed my concerns other moments, but here it is again: Project A uses for instance Seaside stable which is, when Project A starts Seaside 3.0 time after owner tries to load Project A… but since then stable from Seaside has move from Seaside 3.0, to 3.1.2 now… that can be “not desired” at all. Project A wanted Seaside 3.0, not 3.1 (of course, if using Semantic Versioning that will mean there is just changes to the API in a compatible way… but we all know we do not use semver correctly almost never). So… in fact Project A cannot depend on Seaside/#stable… instead, he should depend on Seaside/3.0 directly to be sure you have the version you want. that of course introduces other kind of problems, like: what happens if I want to install Project A who depends on Seaside/3.0 and Project B who depends on Seaside/3.0.2 Well… ideally, we need to be able to resolve those problems when loading. Also, it would be cool to specify version dependencies as “Seaside/3.*”, for instance… but well… that’s another thread :) As you can see… is not an easy task. Esteban
|
Re: Probably Metacello sucks…
|
|
On 12-06-15 09:34, Esteban Lorenzano wrote:
> Project A uses for instance Seaside stable which is, when Project A > starts Seaside 3.0 > time after owner tries to load Project A… but since then stable from > Seaside has move from Seaside 3.0, to 3.1.2 Seaside is the one example where we are using semantic versioning, precisely because we ran into the problems you described. We have #'release3', #'release3.0' #'release3.1' and will soon have #'release3.2'. #'release3' points to #'release3.1', so if you don't care about the api changes from 3.0 to 3.1 you'll just use the latest stable. Otherwise, use #'release3.1'. We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo. So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'. > that of course introduces other kind of problems, like: what happens >if I want to install Project A who depends on Seaside/3.0 and >Project B who depends on Seaside/3.0.2 Yep, both should depend on #'release3.0'. That way, your code might even run on Pharo 4, and profit from the bug fixes done between 3.0.2 and the current 3.0.16 Stephan |
|
|
it was just an example of why using #stable in project dependences is a bad idea :)
you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice… who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say “3.*”) btw… IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever… they are used to describe and publish projects people actually can download and use. Any version: 3.0 3.0.1 3.1 … etc. is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. we need to separate the concept of “artifact released” and “development branch”, and we need to stop using versions as commits. In my opinion development cycle should be: we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc. I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. cheers, Esteban > On 12 Jun 2015, at 10:04, Stephan Eggermont <[hidden email]> wrote: > > On 12-06-15 09:34, Esteban Lorenzano wrote: >> Project A uses for instance Seaside stable which is, when Project A >> starts Seaside 3.0 >> time after owner tries to load Project A… but since then stable from >> Seaside has move from Seaside 3.0, to 3.1.2 > > Seaside is the one example where we are using semantic versioning, > precisely because we ran into the problems you described. > We have #'release3', #'release3.0' #'release3.1' and will soon have > #'release3.2'. #'release3' points to #'release3.1', so if you don't > care about the api changes from 3.0 to 3.1 you'll just use the > latest stable. Otherwise, use #'release3.1'. > > We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo. > > So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'. > >> that of course introduces other kind of problems, like: what happens >> if I want to install Project A who depends on Seaside/3.0 and > >Project B who depends on Seaside/3.0.2 > > Yep, both should depend on #'release3.0'. That way, your code might > even run on Pharo 4, and profit from the bug fixes done between 3.0.2 > and the current 3.0.16 > > Stephan > > > > |
Re: Probably Metacello sucks…
|
|
On 12-06-15 10:24, Esteban Lorenzano wrote:
> it was just an example of why using #stable in project dependences is a bad idea :) > you made #releaseN.N to fix precisely my point. > there should exist something like I say “3.*” #'release3' always refers to the latest stable 3.*.*.* > I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o. Stephan |
|
|
> On 12 Jun 2015, at 10:40, Stephan Eggermont <[hidden email]> wrote: > > On 12-06-15 10:24, Esteban Lorenzano wrote: >> it was just an example of why using #stable in project dependences is a bad idea :) >> you made #releaseN.N to fix precisely my point. >> there should exist something like I say “3.*” > > #'release3' always refers to the latest stable 3.*.*.* I know :) I’m just saying that I would like to have that as a standard mechanism, not a convention. Esteban > >> I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. > > I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). > That would be better handled with a (separate) SnapshotOf class i.m.o. > > Stephan > > > |
|
|
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you can’t so you have to use the uber-long script on the Woden project page instead of conf. That’s why I’ve joked about using scripts instead of Metacello. Uko > On 12 Jun 2015, at 12:25, Esteban Lorenzano <[hidden email]> wrote: > > >> On 12 Jun 2015, at 10:40, Stephan Eggermont <[hidden email]> wrote: >> >> On 12-06-15 10:24, Esteban Lorenzano wrote: >>> it was just an example of why using #stable in project dependences is a bad idea :) >>> you made #releaseN.N to fix precisely my point. >>> there should exist something like I say “3.*” >> >> #'release3' always refers to the latest stable 3.*.*.* > > I know :) > I’m just saying that I would like to have that as a standard mechanism, not a convention. > > Esteban > >> >>> I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. >> >> I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). >> That would be better handled with a (separate) SnapshotOf class i.m.o. >> >> Stephan >> >> >> > > |
|
|
On Fri, Jun 12, 2015 at 1:48 PM, Yuriy Tymchuk <[hidden email]> wrote: Just a quick side note: As a sidenote (and since Yuriy mentioned Roassal), we would like to address the versioning (and release management) of roassal at ESUG (Camp Roassal) since Roassal was being developed really fast and it was hard to keep up. Semver is good for not breaking things (if applied properly), but I feel it hides a little bit the extent of change... a project could go from version 1 to 10 with several very little bc-breaks and then from 10 to 11 there would be complete redesign... and you can't tell the difference just looking at the number, which is bad for updating ( As for #stable, etc., they are very useful for tools which I only use as a user... e.g. PharoLauncher or QualityAssistant my 2¢ Peter |
Re: Probably Metacello sucks…
|
|
In reply to this post by EstebanLM
On 06/12/2015 01:24 AM, Esteban Lorenzano wrote: > it was just an example of why using #stable in project dependences is a bad idea :) > you made #releaseN.N to fix precisely my point. > but since this is a convention of Seaside and not a regular practice… who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say “3.*”) > > btw… IMO other frequent misunderstanding is the use of metacello as description for nightly builds. > metacello (and any dependency manager) should be use *just* for releases. > think other dependecy managers around: maven, npm or whatever… they are used to describe and publish projects people actually can download and use. > Any version: > > 3.0 > 3.0.1 > 3.1 > … > etc. > > is a loadable and usable version. > the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. > > we need to separate the concept of “artifact released” and “development branch”, and we need to stop using versions as commits. > In my opinion development cycle should be: > > we release version 1.0 > then we develop in bleeding edge lets say for doing a version 1.1 > we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 > we continue in #bleedingEdge until we are ready to: > 1.1-alpha > 1.1-beta > 1.1-rc1 > 1.1 > we repeat the cycle for next version > etc. > > I’m sorry for being obvious here, I know this is known… problem is that I’ve seen far too much the use of metacello not for doing releases but to handle commits. > Esteban, this point is exactly the reason that I am a proponent of using git. Branches are first class objects in git and provide exactly the type of functionality that is needed for doing development where problems are being solved on multiple fronts. I've added features to the Metacello Scripting API over the last couple of years to make it possible to switch between github-based repos and local git clones which is critical for development and So I don't think that "Metacello shouldn't be used for nightly builds", but that "ConfigurationOf shouldn't be used for nightly builds":) I've recently posted an article on the Metacello news group[1] where I talk in more detail about using Metacello and git for development. Dale [1] http://forum.world.st/GitHub-Configs-tp4830432p4830673.html |
|
|
… and of course I agree 100% with you :)
the real problem is how do we get there, and I’m thinking not just the tools, but the “cultural change”. Esteban
|
|
|
In reply to this post by Peter Uhnak
+1
> On Jun 12, 2015, at 9:36 AM, Peter Uhnák <[hidden email]> wrote: > > As a sidenote (and since Yuriy mentioned Roassal), we would like to address the versioning (and release management) of roassal at ESUG (Camp Roassal) since Roassal was being developed really fast and it was hard to keep up. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Probably Metacello sucks…
|
|
In reply to this post by EstebanLM
Esteban,
Yeah, it can take time for the culture to change, but the tools do have to be in place and the early adopters have to beat those tools into shape ... we are in this phase at the moment I think... once the tools are in place, then the projects that are feeling the most pain will have the opportunity to make the transition with a minimum amount of fuss and if the pain is reduced (which I expect to happen) others will follow ... Dale On 06/13/2015 12:56 AM, Esteban
Lorenzano wrote:
… and of course I agree 100% with you :) |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |