Hi,
I'm updating the the baseline of PharoJS to use the zinc websockets from the github repo https://github.com/svenvc/zinc . I want to load package Zinc-WebSocket-Core . So, in BaselineOfPharoJS>>#baseline: I've defined
However, for some reason I get Zinc-WebSocket-Tests loaded. Any hint how to avoid it?Looking at BaselineOfZincHTTPComponents>>#baseline: , package WebSocket-Core does not seem to depend on tests
Thanks, Noury
|
Yeah - I have a similar issue with ExternalWebBrowser, which I load as:
spec baseline: 'ExternalWebBrowser' with: [ spec repository: '<a href="github://seandenigris/Pharo-Web-Browser:master/repository" class="">github://seandenigris/Pharo-Web-Browser:master/repository' ]; import: 'ExternalWebBrowser'. That drags in BabyMock and huge raft of tests (which I’m grateful were written), but I’d prefer not to muddy the waters when presenting Exercism. I think what we have to do is submit pull requests to these projects such that they create better baselines with Groups. Eg. The Exercism baseline does this so that students load core, but developers get extra tools to generate exercises - eg. spec package: 'Exercism' with: [ ]; package: 'ExercismDev' with: [ spec requires: #('Exercism' 'ExercismTools')]; package: 'ExercismTools' with: [ spec requires: #('OSProcess' 'ExternalWebBrowser') ]; group: 'default' with: #('ExercismTools'); group: 'dev' with: #('ExercismDev’)] Then you can specify in your load request which group to use (I don’t have the syntax handy for baselines, but when you load via iceberg, the Metacelle menu has a second option where you specify the group to use, so I’m sure it can be done in code too). I’d be interested if there is some way to do it without groups though, so that you don’t have to rely on the package authors to do this (similar in thought to what Sabine is complaining about by not being able to better control version dependencies). This whole area is becoming more and more important as we grow up and what to have more controllable load characteristics. Tim
|
Administrator
|
Tim Mackinnon wrote
> Yeah - I have a similar issue with ExternalWebBrowser... that drags in... > [a] huge raft of tests My workflow is to make every project one monolithic package until the need to do otherwise is presented (like right now!). I used to carefully think about theoretical use case scenarios and split projects up along those lines, but management (especially with the tooling available at that time) seemed to explode exponentially, so I went monolithic. After several years of experience, this is the first time someone expressed a pain point (that I remember anyway)! This seems to validate the current approach and my suspicion that preemptively creating multiple packages is akin to premature optimization. Tim Mackinnon wrote > I think what we have to do is submit pull requests to these projects such > that they create better baselines with Groups Yes! I will happily integrate. The tests may need to be promoted to a package if they are currently in a tag, but 'Core' without and 'Tests' with seems appropriate given your issue. I don't have a strong opinion on the default but my guess is to leave it as is (i.e. all packages) because newbies will get the tests (i.e. documentation) and advanced users will know enough to customize. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
Free forum by Nabble | Edit this page |