Package depending on the OS ?

[Mariano Martinez Peck]

Dale: I remember and understood perfectly the Metacello feature of having a platform specific package. Like MyApp-Pharo, MySpp-Gemstone....etc.
Then I also understood the project properties and the conditional loading.

Now, what I wonder is if it could be a good idea to have some feature to load specific platform packages what where the platform is actually the OS, but not the Smalltalk dialect. Maybe even the same functionality, but instead of asking the dialect, asking the OS. Thus, when loading, it will only load the package of that OS.

I am not hurry at all and I even don't need it right now. It can be 1.1, 1.2 o even 2.0 if you want. Just wanted to discuss the idea.

Cheers

Mariano

[Dale Henrichs]

Mariano,

I think that this would be a good idea ... as soon as we have a concrete need I think we should add it ... it won't require a change in the api...

Dale

[Torsten Bergmann]

This question has more in it ...

What about a package that is only known to work from Pharo 1.1 onwards
and not in Pharo 1.0.

Or in Squeak trunk and Squeak 3.8 but not in Squeak 3.7.

We already have a notation for #requires: but used for package
dependencies.

Here we cross the border to non-packaged base systems, how can we
define a specific version/build nr/image
version as prerequisites?

[Simon Denier]

I think what you describe is related to embedded configurations in configuration.

ConfigurationOfMoose 4.0 depends on ConfigurationOfMondrian 2.0 for example
Then ConfigurationOfMoose 4.1 will depend on ConfigurationOfMondrian 2.4 ....

The same thing with ConfigurationOfPharo should work, right? The strange thing perhaps is that you have to explicitly declare Pharo as a dependency of your project, but it should not be a problem.

--
Simon

[Dale Henrichs]

Simon,

I think it's a slightly different question, because the core isn't managed by Metacello.

I think a simple example would be to look at how Utilitilies class>>authorInitials has migrated to Author>>fullName. This is a simple problem with a number of possible solutions, one of which would be to load a different package (you really are running on a different "platform").

So the question is can you distinguish Pharo 1.0 from Pharo 1.1 and the answer is yes. For GemStone I've found that I've needed to distinguish between versions 2.x, 2.3.x, 2.4.x and 3.x.

There is a platform class for each of the three platforms: MetacelloSqueakPlatform, MetacelloPharoPlatform, and MetacelloGemStonePlatform. MetacelloPlatform class>>current arranges to point to an instance of the appropriate platform class. The message #defaultPlatformAttributes is sent to that instance.

Right now on Pharo, the method is implemented to return:

#(#squeakCommon #pharo )

On GemStone, the method is implemented as:

| stoneVersionAtts |
(stoneVersionAtts := self stoneVersionAttributes) ifNil: [^ #( #gemstone )].
^ stoneVersionAtts

and #stoneVersionAttrivutes is implemented as:

stoneVersionAttribute isSymbol ifTrue: [ stoneVersionAttribute := nil ].
stoneVersionAttribute ifNil: [ | gsVersion |
stoneVersionAttribute := ((gsVersion := System stoneVersionAt: 'gsVersion') beginsWith: '2.')
ifTrue: [
(gsVersion beginsWith: '2.3')
ifTrue: [ #( #gemstone #'gs2.x' #'gs2.3.x' ) ]
ifFalse: [
(gsVersion beginsWith: '2.4')
ifTrue: [ #( #gemstone #'gs2.x' #'gs2.4.x' ) ]
ifFalse: [ #( #gemstone #'gs2.x' ) ]]]
ifFalse: [#( #gemstone #'gs3.x' )]].
^ stoneVersionAttribute

stoneVersionAttribute is an IV, so the calculation only needs to be done once.

A similare method could be written for Pharo (and Squeak) to allow differentiation across platform versions.

The platform version attributes can be used in a for:do:, just like #squeak, #pharo, etc.

If finer-grained versions are needed it still is possible for a particular project to add it's an attribute in the ConfigurationOf (see ConfigurationOfGemTools>>project and the logic for creating the #'pharo1.0Beta' attribute).

If this doesn't cover the playing field, then we can discuss additional alternatives.

Dale

[Sean DeNigris]

> I think a simple example would be to look at how Utilitilies class>>authorInitials has migrated to Author>>fullName. This is a simple problem with a number of possible solutions, one of which would be to load a differentpackage(you really are running on a different "platform").

>
> So the question is can you distinguish Pharo 1.0 from Pharo 1.1 and the answer is yes. For GemStone I've found that I've needed to distinguish between versions 2.x, 2.3.x, 2.4.x and 3.x.

I think this will be really important down the road to avoid the mess
with Squeak now where you have to load packages with little
documentation that are X years old, and cross your fingers to see if
it will run on your version.

You can easily get Pharo's version:
SystemVersion current majorMinorVersion. "e.g. 'Pharo-1.0'"

> A similare method could be written for Pharo (and Squeak) to allow differentiation across platform versions.

I'd be happy to write it. Is the above format definitely how it's
going to look e.g. #'ph[number].x' ... I'd prefer to spell the name
out fully for clarity (and possible expanding forks/names down the
line)

Brainstorming: it seems like ranges could be useful too, like
pharo1.0-1.7

Sean


--
Subscription settings: http://groups.google.com/group/metacello/subscribe?hl=en

[Dale Henrichs]

Sean,

I'm waiting for the time when we have a clear requirement, before inserting this into Metacello itself. Individual Configurations can be written with methods that adjust for version ...

I would think that at the point that a number of projects find themsevles needing to differentiate then we can add the capability. Until then I think that it would be useful to explore the possibilities - I've created http://code.google.com/p/metacello/issues/detail?id=71 to record specific algorithms and ideas so when the time comes to really solve the problem, we'll have a number of different approaches to choose from (hopefully).

Dale

[Sean DeNigris]

> I would think that at the point that a number of projects find themsevles needing to differentiate then we can add the capability. Until then I think that it would be useful to explore the possibilities - I've createdhttp://code.google.com/p/metacello/issues/detail?id=71to record specific algorithms and ideas so when the time comes to really solve the problem, we'll have a number of different approaches to choose from (hopefully).

k, sounds good. thx.

[Sean DeNigris]

> Individual Configurations can be written with methods that adjust for version ...

Would that be through preLoadDoIt?

[Sean DeNigris]

This is what's driving my questions (I need to install differently
between Pharo 1.0 and 1.1)...

I have:
1. SSpec - which holds all the #common code (I'll eventually split
it up into core/tests/etc, but it exists as one big package right now)
2. SSpec-Platform
a. SSpec-Platform.pharo
b. SSpec-Platform.squeak

Everything works like a charm on Pharo 1.1 and Squeak 4.1.

So... the only piece left is what to do on Pharo 1.0, since the code
that broke the package (pragma world menu) didn't come along until
1.1.

What needs to happen is that Pharo 1.0 uses the same code as Squeak.

How would I accomplish that?

Thanks!
Sean

[Sean P. DeNigris]

No ideas? This problem is nagging on a few different projects.

Thanks.
Sean
--
View this message in context: http://forum.world.st/Package-depending-on-the-OS-tp1556355p2064561.html
Sent from the Metacello mailing list archive at Nabble.com.

[Dale Henrichs]

Sean,

Sorry for not getting back to you earlier. Take a look a ConfigurationOfGemTools>>project. In that method I created a #'pharo1.0Beta' attribute by looking at the SystemVersion current version...

Dale
----- "Sean DeNigris" <sean.p....@gmail.com> wrote:

[Sean DeNigris]

On Apr 29, 6:14 pm, Dale Henrichs <dale.henri...@gemstone.com> wrote:
> Take a look a ConfigurationOfGemTools>>project. In that method I created a #'pharo1.0Beta' attribute by looking at the SystemVersion current version...

This looks like exactly what I need - thanks a lot!

Sean

[Sean DeNigris]

On Apr 21, 12:25 pm, Dale Henrichs <dale.henri...@gemstone.com> wrote:
> I'm waiting for the time when we have a clear requirement, before inserting this into Metacello itself. Individual Configurations can be written with methods that adjust for version ...

I think I've encountered a requirement, but from the user end:
Metacello Configurations definitely simplify dependency management.
When it works, it's awesome! Where I am hitting the wall is managing
compatibility with different flavors of Squeak. Let me recount my
latest experience...

> I want to install ExternalWebBrowser.
> Oh good, there is a ConfigurationOf... in the SqS MetacelloRepository
> Let me make sure it works and then I'll add it to my ImageSetup script
> Results
> Pharo 1.1 trunk update 11364: ExternalWebBrowserMacOS class>>isApplescriptAvailable references SMSqueakMap, which was removed from Pharo. Ugh, okay, I'll manually install Applescript via Gofer and Monticello, then restart
> Pharo 1.0: same problem
> Squeak 4.1 trunk update 10145: MetacelloMCProjectSpec's instance variable 'className' is nil; when asSymbol is called on it, DNU asSymbol
> Squeak 4.1 official release: same problem

So my question is - what platform does this config target? It failed
for all the current Squeak and Pharo images!

As a user, I would like to either:
* have a specific place (depending on my platform) to find the correct
config
* or, even easier (and I suspect much less duplication, since many
configs may work with multiple platforms), a way to mark
ConfigurationsOf as working with particular platforms. Then, you
could at least issue a warning, like SqMap, that 'the Config was not
approved for this platform, do you want to continue.' If this info
was built into the Metacello model, one might even be able to query
the MetacelloRepository for configs approved for the current platform.

The way it is now, I think I spent more time above than manually
resolving the dependencies.
What are your experiences with this issue, if any?

Thanks.
Sean

[Mariano Martinez Peck]

On Sat, May 15, 2010 at 2:55 AM, Sean DeNigris <sean.p....@gmail.com> wrote:

On Apr 21, 12:25 pm, Dale Henrichs <dale.henri...@gemstone.com> wrote:
> I'm waiting for the time when we have a clear requirement, before inserting this into Metacello itself. Individual Configurations can be written with methods that adjust for version ...

I think I've encountered a requirement, but from the user end:
Metacello Configurations definitely simplify dependency management.
When it works, it's awesome!  Where I am hitting the wall is managing
compatibility with different flavors of Squeak.  Let me recount my
latest experience...

> I want to install ExternalWebBrowser.
> Oh good, there is a ConfigurationOf... in the SqS MetacelloRepository
> Let me make sure it works and then I'll add it to my ImageSetup script
> Results
>     Pharo 1.1 trunk update 11364: ExternalWebBrowserMacOS class>>isApplescriptAvailable references SMSqueakMap, which was removed from Pharo.  Ugh, okay, I'll manually install Applescript via Gofer and Monticello, then restart
>     Pharo 1.0: same problem
>     Squeak 4.1 trunk update 10145: MetacelloMCProjectSpec's instance variable 'className' is nil; when asSymbol is called on it, DNU asSymbol
>     Squeak 4.1 official release: same problem

So my question is - what platform does this config target?  It failed
for all the current Squeak and Pharo images!

First, this is not up to Metacello. I mean, Metacello WILL NOT help to make your software cross-platfrom. YOU will have to do that. Of course, you can try to use tools such as Grease or Sport.

 

As a user, I would like to either:
* have a specific place (depending on my platform) to find the correct
config

What Metacello provides you is a way to easily manage packages that depends on the platform. Thus, if you have your package MyApp-Platform-Squeak and MyApp-PlatformPharo Metacello will help you to load the correct package in each platfrom. But again, YOU have to provide the different platform packages.
 

* or, even easier (and I suspect much less duplication, since many
configs may work with multiple platforms), a way to mark
ConfigurationsOf as working with particular platforms.  Then, you
could at least issue a warning, like SqMap, that 'the Config was not
approved for this platform, do you want to continue.'  If this info
was built into the Metacello model, one might even be able to query
the MetacelloRepository for configs approved for the current platform.

The way it is now, I think I spent more time above than manually
resolving the dependencies.

You are not resolving dependencies, you are resolving portability problem across dialects.

 

[Sean DeNigris]

Thanks for the response (comments inline)

On May 15, 9:55 am, Mariano Martinez Peck <marianop...@gmail.com>
wrote:

> First, this is not up to Metacello. I mean, Metacello WILL NOT help to make
> your software cross-platfrom. YOU will have to do that. Of course, you can
> try to use tools such as Grease or Sport.

Yes, sure. I'm saying that it should be obvious from looking at a
ConfigurationOfXxx what platforms/versions it works on (e.g. possibly
based on where it is located, which is not a Metacello library issue
per se, or maybe as part of the model).

> What Metacello provides you is a way to easily manage packages that depends
> on the platform. Thus, if you have your package MyApp-Platform-Squeak and
> MyApp-PlatformPharo Metacello will help you to load the correct package in
> each platfrom. But again, YOU have to provide the different platform
> packages.
>

> You are not resolving dependencies, you are resolving portability problem
> across dialects.

Yes again - I'm so glad we agree ;-) What I'm suggesting is extending
the platform-management from 'which forks?' to 'which versions of
which forks?' As it stands, I have the platform packages all cooked
up, and I can put them into the config through the project hack a la
ConfigurationOfGemTools, but there is no way in the spec model for a
user to tell if my Config should work on e.g. Pharo 1.1 specifically.
And, if a user has to overcome 'why didn't this Config work on my
platform' errors, at least in my last experience, it overwhelms the
cool dependency-resolving that Metacello provides.

And, as a developer, when I encountered the errors with
ExternalWebBrowser, because I did not know what platform version it
was supposed to work on, it was not obvious how to contribute a fix to
the community - especially if Pharo 1.0, Pharo trunk, Squeak 4.1, and
Squeak trunk, etc. all need different platform-specific pieces -
unless I knew about the ConfigurationOfGemTools approach. Let's make
this a part of the model and empower the community to write and port
code cross-platform!

Sean

[Dale Henrichs]

Sean,

The only difficulty I see in trying to do an across the board inclusion of platform versions in the attributes is that it's isn't clear which level of granularity is appropriate.

Should the standard versions be:

Pharo1.0
Pharo1.1
Pharo1.1.1

or should the granularity be finer than that and include the build number...

In GemStone I found that I needed to do things like:

2.3.x
2.4.x

to cover intermediate releases...it wasn't necessary (so far) to go any farther, but that doesn't mean that a particular project won't have dependencies upon 2.3.1.

I think that as Pharo1.1 goes into development that we will see patterns emerge for Pharo that will end up being covered in the "standard attributes"

Dale
----- "Sean DeNigris" <sean.p....@gmail.com> wrote:

[Sean DeNigris]

> The only difficulty I see in trying to do an across the board inclusion of platform versions in the attributes is that it's isn't clear which level of granularity is appropriate.
>
> Should the standard versions be:
>
>   Pharo1.0
>   Pharo1.1
>   Pharo1.1.1
>
> or should the granularity be finer than that and include the build number...

This may be totally out of nowhere, but could for:do: take a block?
In other words, instead of being restricted to for: #squeak do:, one
could say:

for: [ spec squeak version: '4.0' to: '4.1' ] do: [...]

Another thought is allow a simple regex - maybe use 'x' as 'anything
for this part of the version'

Just brainstorming...

Sean

[Sean DeNigris]

On Sunday, May 16, 2010 at 10:46:26 AM UTC-4, Sean DeNigris wrote:

This may be totally out of nowhere, but could for:do: take a block?
In other words, instead of being restricted to for: #squeak do:, one
could say:

for: [ spec squeak version: '4.0' to: '4.1' ] do: [...]

Another thought is allow a simple regex - maybe use 'x' as 'anything
for this part of the version' 

 I know this is a super old thread, but… did we ever add anything to the API to specify a range of platform versions? It would be useful to say "Pharo 5+" because w/o that it seems that Configs/Baselines have to be updated after each new platform release, even if nothing has changed…

[Tobias Pape]

Hi Sean

You can do:

for: #( #'squeak4.1.x' #'squeak4.2.x' #'squeak4.3.x' ) do: [..]

it's rather verbose but works! :)

Best regards
-Tobias


>
> --
> You received this message because you are subscribed to the Google Groups "Metacello" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sean DeNigris]

You can do: for: #( #'squeak4.1.x' #'squeak4.2.x' #'squeak4.3.x' ) do: [..] 

Thanks. I was hoping for something that avoids changing the baseline every time a new platform version is released e.g. >=squeak4.x

[Dale Henrichs]

Sean,

What Tobias suggests is the way it is done today ... I am still trying
to avoid relying on Smalltalk code to specify baselines --- it's a
security risk to have to execute smalltalk code in order to figure out
what packages are needed for download/load, so I prefer to use Smalltalk
literals for the configuration specification ... just imagine that the
configuration/baseline is specified using STON.

I am willing to consider variations on this theme:

  spec for: #'squeak4.[1-3].x' do: [...]

or:

  for: #'squeak4.*.x' do: [...]

or:

  ???


Dale

[Tobias Pape]

> On 23.02.2018, at 15:02, Dale Henrichs <dale.h...@gemtalksystems.com> wrote:
>
> Sean,
>
> What Tobias suggests is the way it is done today ... I am still trying to avoid relying on Smalltalk code to specify baselines --- it's a security risk to have to execute smalltalk code in order to figure out what packages are needed for download/load, so I prefer to use Smalltalk literals for the configuration specification ... just imagine that the configuration/baseline is specified using STON.
>
> I am willing to consider variations on this theme:
>
> spec for: #'squeak4.[1-3].x' do: [...]
>
> or:
>
> for: #'squeak4.*.x' do: [...]
>
> or:
>
> ???
>

while it is cumbersome, the current variant makes sure that we actually touch the baselines when new Platform versions emerge.
I think this is a plus and helps avoiding bit rot.

An override system would help to test on new platform versions.
So one could easily say,
- I am on version Y
- load as if I were on version X
If that works, add version Y to the list, if not, you need a new #for:do: in any case…

Best regards
-Tobias

[Dale Henrichs]

On 02/23/2018 10:00 AM, Tobias Pape wrote:
>> On 23.02.2018, at 15:02, Dale Henrichs <dale.h...@gemtalksystems.com> wrote:
>>
>> Sean,
>>
>> What Tobias suggests is the way it is done today ... I am still trying to avoid relying on Smalltalk code to specify baselines --- it's a security risk to have to execute smalltalk code in order to figure out what packages are needed for download/load, so I prefer to use Smalltalk literals for the configuration specification ... just imagine that the configuration/baseline is specified using STON.
>>
>> I am willing to consider variations on this theme:
>>
>> spec for: #'squeak4.[1-3].x' do: [...]
>>
>> or:
>>
>> for: #'squeak4.*.x' do: [...]
>>
>> or:
>>
>> ???
>>
> while it is cumbersome, the current variant makes sure that we actually touch the baselines when new Platform versions emerge.
> I think this is a plus and helps avoiding bit rot.

This is a good point ... and one should touch the .travis.yml file at
the same time (per version here as well)  ... I'm inclined to leave well
enough alone for the time being ... but still want to hear additional
arguments ... both pro and con ...

>
> An override system would help to test on new platform versions.
> So one could easily say,
> - I am on version Y
> - load as if I were on version X
> If that works, add version Y to the list, if not, you need a new #for:do: in any case…

What would such a thing look like?

I can imagine doing something like the when running on platform
'squeak4.6.x':

  Metacello new
    baseline: '...';
    repository: '...';
    addDefaultAttribute: #( 'squeak4.5.x' );
    load

'squeak4.5.x' would be added to the platform default attribute list and
make it appear that you are running on a squeak4.5.x ...

As I think about this things could get weird if some projects being
loaded due to dependencies did already have squeak4.6.x behavior
different from squeak4.5.x, so I'm not sure that this would actually
make things easier ... in simple cases it could work, but the more
complicated projects could lead to totally unexpected behavior...

Dale

[Tobias Pape]

HI Dale

That's actually what I do for Squeak trunk (Aka alpha):

https://github.com/Metacello/metacello/blob/master/repository/Metacello-Platform.squeak.package/MetacelloSqueakPlatform.class/instance/defaultPlatformAttributes.st#L15

>
> As I think about this things could get weird if some projects being loaded due to dependencies did already have squeak4.6.x behavior different from squeak4.5.x, so I'm not sure that this would actually make things easier ... in simple cases it could work, but the more complicated projects could lead to totally unexpected behavior...

That I understand. What about

Metacello new
baseline: '...';
repository: '...';

addDefaultAttribute: #'squeak4.5.x' inPlaceOf: #'squeak4.6.x';
load

?

Best regards
-Tobias