Runar, This week at the STIC conference, there has been a little headway made towards sharing source code between Smalltalk dialects (and the issue of what to do about package dependencies has come up) ... As part of my presentation at STIC[1], I argued that git/github is a good vehicle for sharing Smalltalk between dialects and that message got some traction with most of the attendees and a little project called Cypress[2] was started with a few folks who are going to collaborate on a cross dialect, disk-based package import/export format.
Work on VW and Amber variants for Cypress was started at the Camp Smalltalk yesterday and there is a VAST developer involved as well. The Cypress project was inspired by the FileTree[3] project which was originated by Otto Behrens. The FileTree project provides a disk-based package structure based on Monticello and the Cypress project is focussed on generalizing the format to accomodate multiple Smalltalk dialects. The FileTree code works for Pharo and Squeak and there will be a port to GemStone coming. The FileTree project and the Cypress projects will eventually share same structure on disk... While the package formats being discussed are SCM neutral, the idea is to use git/github for sharing source code between dialects ... Keep an eye on Cypress project for developments and if you have feedback, we are using the Cypress issue list[4] for Cypress related conversations beyond just bug reports... More work on Cypress will be done today ... Dale [1] http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk [2] https://github.com/CampSmalltalk/Cypress [3] https://github.com/dalehenrich/filetree [4] https://github.com/CampSmalltalk/Cypress/issues ----- Original Message ----- | From: "Runar Jordahl" <[email protected]> | To: "A friendly place where any question about pharo is welcome" <[email protected]> | Sent: Tuesday, March 20, 2012 1:22:11 AM | Subject: Re: [Pharo-users] Defining Prerequisites in Packages | | Thanks for your answer. | | I have read this document and I know that dependencies can be defined | in Metacello configuration classes. I guess I question whether this | is | the best location to store package dependencies. | | If, for example, I were to port my integration with DTangler to | Pharo, | I am unsure how the tool will be able to find dependencies for a | given | package. Would it need to search though ConfigurationOf-classes? How | would it determine the correct version to use, etc? Maybe it can be | done, but it would be harder than VisualWorks’ approach were you have | this information directly in the package. | | Also consider that you might want to query dependencies not just for | a | single project (like Seaside), but for the entire image. Using a | single ConfigurationOf-class, might not be sufficient. | | Then again, I do not have much knowledge of Pharo. Maybe Pharo’s | approach makes sense once I start using it… | | Is my understanding correct when I expect Pharo to continue having | package dependencies only defined in Metacello configuration classes? | | Kind regards | Runar Jordahl | |
