Pushing Amber

On 5/30/12, [hidden email] <[hidden email]> wrote:
Not for me. I appreciate to have a more user friendly file structure.

--Hannes

Well said! 

Hi Dale and all!

On 05/31/2012 10:53 PM, Dale Henrichs wrote:
> Göran,
>
> I'll take your bait:)

:)

Mmmm, well, although I am all *for* any and all solutions ;) (the
principle that we are too few to "stifle" any initiatives) I would
prefer a "package model" that is independent of server solution.

In fact, I would list a few properties that I would like:

1. Independent of server tech. :) Amber is already being used with non
Smalltalk backends etc. And also with *no* backend.

2. Very simple. It should IMHO be limited to the very smallest needed
things, and not at all be aimed at the jungle of source code management.

3. Have a working dependency model. But I think it should be along the
"works in 90% of the cases, easily overridden for the other 10%".


Now, if we follow the above this could hopefully still work *together*
with server side solutions. For example, one approach would be:

1. Establish a minimum set of package meta data, perhaps for the package
called 'MyPackage' it could be:

        url -> 'http://wherever/MyPackage.js'.
        license -> 'http://wherever/License.txt'.
  "best is probably a URL to the license text or the license text itself"
        author -> 'Göran Krampe <[hidden email]>'.
        version -> '1.24 alpha'                    "no specific rules"
        dependencies -> {'OtherPackage'. 'OneMorePackage' -> '1.01'}

2. Build a very simple dependency resolver. If we support:
        a) Dependency by package name  (Amber will try to find it)
        b) Dependency by package URL   (Amber will simply use URL)
        b) Dependency with criteria    (...sky is limit here)


NOTE: Criteria could then be simply a string, and then we can start
playing inside that string with for example ">1.01", "=1.1" or ">=1.0"
and so on.


Examples of optional metadata would be:

        source -> 'http://wherever/MyPackage.st'       "optional"
        homepage ->
       
...and so on. Now, packages can already keep the metadata described
above, I built the mechanism for that. So we would just need to:

        - Decide on metadata (for example as above)
        - Add a little bit of code to make those fields easy to mess with
(basically getters and setters on Package)
        - Add a bit of UI perhaps to set these fields :)
        - Write a little resolver.

And the resolver should become very small since:

- Packages are single files and reachable by URL.
- Packages have all their metadata embedded in the file, no need for a
catalog or anything.

One little trick the resolve should need is that it should be able to
only load the metadata (comes first in file, js or st) - so that it can
find dependencies etc recursively, before it actually loads anything.

Ok, so Dale, we are coming at this from two different angles - how does
the above sound to you? I mean, if we agree on metadata then I can't see
any harm in having different kinds of resolvers, client or server side etc.

regards, Göran

Hey Göran...

----- Original Message -----
| From: "Göran Krampe" <[hidden email]>
| To: [hidden email]
| Sent: Monday, June 4, 2012 5:27:54 AM
| Subject: Re: [amber-lang] Pushing Amber
|
| Hi Dale and all!
|
| On 05/31/2012 10:53 PM, Dale Henrichs wrote:
| > Göran,
| >
| > I'll take your bait:)
|
| :)
|
| > My thoughts so far have circled around the fact that the
| > dependencies could/should(?) be resolved on the server side ... no
| > need for the client-code to worry about package dependencies ...
| > the server is close to the file system so it should do the heavy
| > lifting ...
| >
| > If we are using Pharo/Squeak/GemStone as a server, one _could_ use
| > Metacello configurations to manage dependencies ... in fact it
| > would be simple to manage the server and client code in the same
| > configuration....
| >
| > I'm in the middle of creating a scripting API that allows one to
| > specify a load that looks like the following:
| >
| >    Metacello new
| >      project: 'STON';
| >      version: '1.0';
| >      repository:
| >      'https://github.com/dalehenrich/ston:amber/repository';
| >      load.
| >
| > This code _could_ be executed in Amber on the client, with the
| > actual Metacello heavy lifting done on the server side (where
| > Metacello is already running)...a load list could be returned to
| > the client and we'd be off to the races ....
| >
| > The down-side to this approach is that there would be a hell of a
| > lot of work to get Metacello ported to Node.js:)
|
| Mmmm, well, although I am all *for* any and all solutions ;) (the
| principle that we are too few to "stifle" any initiatives) I would
| prefer a "package model" that is independent of server solution.

I'm inclined to agree, but the implementation of a server-independent model is very much complicated by the disparity in the supporting infrastructure between Node and Pharo.

I understand your desire to be "server neutral":

  GemStone does not have a native GUI, so we strive to
  "client neutral", but in practical terms we end up
  writing a fair amount of client-side code that becomes
  tightly coupled to the client smalltalk ... consequently
  we end up doing a better job supporting some clients
  over others.

My issue with Node.js was at the most basic file-system level...the one thing that is missing from Amber (at the moment) and the one thing that must exist when importing exporting _files_.

So in the end, I'm afraid that any client-side implementation modeling will be heavily influenced by the server-side support.

If you insist on being server-neutral, then your client-side model will be limited by the capabilities of the lowest common denominator.

Don't get me wrong, I am truly not disagreeing with this approach, I'm just pointing out that developers with a desire for more capabilities from the development model will be "forced to roll their own" and for something as fundamental as the development environment this might not be a great idea ...

I'm definitely not suggesting that Metacello should be used in Amber (Metacello is solving a different set of problems) ... Metacello is a pragmatic choice on my part ... and will be the quickest route to "rolling my own" dev environment for Amber ... I plan using a Smalltalk-based server that already supports Metacello for my Amber work, and with amber-skeleton, I'm well along the way to having an integrated server/client development environment that makes it real easy to share source code, the SCM and package management.

 
| In fact, I would list a few properties that I would like:
|
| 1. Independent of server tech. :) Amber is already being used with
| non
| Smalltalk backends etc. And also with *no* backend.

Are you talking about a _development environment_ that has no backend?

|
| 2. Very simple. It should IMHO be limited to the very smallest needed
| things, and not at all be aimed at the jungle of source code
| management.

Unfortunately, source code management is a jungle ... side-stepping source code management is an option, but your developers cannot side-step the issue so easily, they are making SCM decisions right now and have to have a working system ...

I'm not familiar enough with javascript to know whether there is a well-accepted packaging model that already exists for javascript ... IMHO, adopting/adapting the javascript model would be the best choice for Amber ...

Reinventing the wheel is the most fun, but adapting/adopting an existing model gets the job done...

|
| 3. Have a working dependency model. But I think it should be along
| the
| "works in 90% of the cases, easily overridden for the other 10%".
|

In my experience, specifying the dependency is not the hard part ... resolving dependencies (finding the correct versions of the files), honoring the dependencies (saving the files where they came from) and loading the files (detecting dependency loops and version conflicts) are the nasty bits, that make SCM a jungle.

|
| Now, if we follow the above this could hopefully still work
| *together*
| with server side solutions. For example, one approach would be:
|
| 1. Establish a minimum set of package meta data, perhaps for the
| package
| called 'MyPackage' it could be:
|
| url -> 'http://wherever/MyPackage.js'.
| license -> 'http://wherever/License.txt'.
|   "best is probably a URL to the license text or the license text
|   itself"
| author -> 'Göran Krampe <[hidden email]>'.
| version -> '1.24 alpha'                    "no specific rules"
| dependencies -> {'OtherPackage'. 'OneMorePackage' -> '1.01'}
|
| 2. Build a very simple dependency resolver. If we support:
| a) Dependency by package name  (Amber will try to find it)
| b) Dependency by package URL   (Amber will simply use URL)
| b) Dependency with criteria    (...sky is limit here)
|

Göran, this is how Metacello started:)....3 years ago ... trust me... it doesn't end there:)

I don't have the bandwidth to invent another package management system:(

My advice is to pick an existing system (javascript or smalltalk-based) and adapt it to Amber. I think that a javascript-based solution would give you traction with javascript developers and I think that could be an important selling point...

I do plan on continuing with amber-skeleton. amber-skeleton is using the current Amber client-side package model and I plan to continue to follow the Amber client-side package model where-ever it leads.

|
| NOTE: Criteria could then be simply a string, and then we can start
| playing inside that string with for example ">1.01", "=1.1" or
| ">=1.0"
| and so on.
|
|
| Examples of optional metadata would be:
|
| source -> 'http://wherever/MyPackage.st'       "optional"
| homepage ->
|
| ...and so on. Now, packages can already keep the metadata described
| above, I built the mechanism for that. So we would just need to:
|
| - Decide on metadata (for example as above)
| - Add a little bit of code to make those fields easy to mess with
| (basically getters and setters on Package)
| - Add a bit of UI perhaps to set these fields :)
| - Write a little resolver.
|
| And the resolver should become very small since:
|
| - Packages are single files and reachable by URL.
| - Packages have all their metadata embedded in the file, no need for
| a
| catalog or anything.
|
| One little trick the resolve should need is that it should be able to
| only load the metadata (comes first in file, js or st) - so that it
| can
| find dependencies etc recursively, before it actually loads anything.
|
| Ok, so Dale, we are coming at this from two different angles - how
| does
| the above sound to you? I mean, if we agree on metadata then I can't
| see
| any harm in having different kinds of resolvers, client or server
| side etc.

Göran, there are some interesting ideas in what you describe above....

However, the package model you adopt must be aimed at a specific development model/system ...

Any changes you make to the package model must be coordinated with changes made to the development model ... For example, you are using urls in your examples above, but you haven't specified how the url will be translated to a specific file on disk or how you will be differentiating urls based on versions of the packages or ... In Metacello I have worked out answers to these questions and others ...

As I've said earlier, I think your best bet is to adopt/adapt an existing Smalltalk or Javascript model and live with it's particular quirks as a quirk-free dependency management system does not exits[1]:

  Any sufficiently advanced dependency management system is
  indistinguishable from Hell

Dale

[1] https://twitter.com/stuartsierra/status/159741771075694594

Dale Henrichs wrote:
npm? it is something like a thing from a few paragraphs above - name,
version, dependencies, file structure, ... and a cli package manager.

Herby

Herby,

Yes, npm is a good example, if you can adapt what npm does to support amber-side development. Does npm have features that manage packages for export to the client or is it strictly for server-side package management?

Dale

----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 5, 2012 11:15:25 AM
| Subject: Re: [amber-lang] Pushing Amber
|
|
|
| Dale Henrichs wrote:
| > Hey Göran...
| >
| > ----- Original Message -----
| > | From: "Göran Krampe"<[hidden email]>
| > | To: [hidden email]
| > | Sent: Monday, June 4, 2012 5:27:54 AM
| > | Subject: Re: [amber-lang] Pushing Amber
| > |
| > | Hi Dale and all!
| > |
| > | On 05/31/2012 10:53 PM, Dale Henrichs wrote:
| > |>  Göran,
| > |>
| > |>  I'll take your bait:)
| > |
| > | :)
| > |
| > |>  My thoughts so far have circled around the fact that the
| > |>  dependencies could/should(?) be resolved on the server side ...
| > |>  no
| > |>  need for the client-code to worry about package dependencies
| > |>  ...
| > |>  the server is close to the file system so it should do the
| > |>  heavy
| > |>  lifting ...
| > |>
| > |>  If we are using Pharo/Squeak/GemStone as a server, one _could_
| > |>  use
| > |>  Metacello configurations to manage dependencies ... in fact it
| > |>  would be simple to manage the server and client code in the
| > |>  same
| > |>  configuration....
| > |>
| > |>  I'm in the middle of creating a scripting API that allows one
| > |>  to
| > |>  specify a load that looks like the following:
| > |>
| > |>     Metacello new
| > |>       project: 'STON';
| > |>       version: '1.0';
| > |>       repository:
| > |>       'https://github.com/dalehenrich/ston:amber/repository';
| > |>       load.
| > |>
| > |>  This code _could_ be executed in Amber on the client, with the
| > |>  actual Metacello heavy lifting done on the server side (where
| > |>  Metacello is already running)...a load list could be returned
| > |>  to
| > |>  the client and we'd be off to the races ....
| > |>
| > |>  The down-side to this approach is that there would be a hell of
| > |>  a
| > |>  lot of work to get Metacello ported to Node.js:)
| > |
| > | Mmmm, well, although I am all *for* any and all solutions ;) (the
| > | principle that we are too few to "stifle" any initiatives) I
| > | would
| > | prefer a "package model" that is independent of server solution.
| >
| > I'm inclined to agree, but the implementation of a
| > server-independent model is very much complicated by the disparity
| > in the supporting infrastructure between Node and Pharo.
| >
| > I understand your desire to be "server neutral":
| >
| >    GemStone does not have a native GUI, so we strive to
| >    "client neutral", but in practical terms we end up
| >    writing a fair amount of client-side code that becomes
| >    tightly coupled to the client smalltalk ... consequently
| >    we end up doing a better job supporting some clients
| >    over others.
| >
| > My issue with Node.js was at the most basic file-system level...the
| > one thing that is missing from Amber (at the moment) and the one
| > thing that must exist when importing exporting _files_.
| >
| > So in the end, I'm afraid that any client-side implementation
| > modeling will be heavily influenced by the server-side support.
| >
| > If you insist on being server-neutral, then your client-side model
| > will be limited by the capabilities of the lowest common
| > denominator.
| >
| > Don't get me wrong, I am truly not disagreeing with this approach,
| > I'm just pointing out that developers with a desire for more
| > capabilities from the development model will be "forced to roll
| > their own" and for something as fundamental as the development
| > environment this might not be a great idea ...
| >
| > I'm definitely not suggesting that Metacello should be used in
| > Amber (Metacello is solving a different set of problems) ...
| > Metacello is a pragmatic choice on my part ... and will be the
| > quickest route to "rolling my own" dev environment for Amber ... I
| > plan using a Smalltalk-based server that already supports
| > Metacello for my Amber work, and with amber-skeleton, I'm well
| > along the way to having an integrated server/client development
| > environment that makes it real easy to share source code, the SCM
| > and package management.
| >
| >
| > | In fact, I would list a few properties that I would like:
| > |
| > | 1. Independent of server tech. :) Amber is already being used
| > | with
| > | non
| > | Smalltalk backends etc. And also with *no* backend.
| >
| > Are you talking about a _development environment_ that has no
| > backend?
| >
| > |
| > | 2. Very simple. It should IMHO be limited to the very smallest
| > | needed
| > | things, and not at all be aimed at the jungle of source code
| > | management.
| >
| > Unfortunately, source code management is a jungle ... side-stepping
| > source code management is an option, but your developers cannot
| > side-step the issue so easily, they are making SCM decisions right
| > now and have to have a working system ...
| >
| > I'm not familiar enough with javascript to know whether there is a
| > well-accepted packaging model that already exists for javascript
| > ... IMHO, adopting/adapting the javascript model would be the best
| > choice for Amber ...
| >
| > Reinventing the wheel is the most fun, but adapting/adopting an
| > existing model gets the job done...
| >
| > |
| > | 3. Have a working dependency model. But I think it should be
| > | along
| > | the
| > | "works in 90% of the cases, easily overridden for the other 10%".
| > |
| >
| > In my experience, specifying the dependency is not the hard part
| > ... resolving dependencies (finding the correct versions of the
| > files), honoring the dependencies (saving the files where they
| > came from) and loading the files (detecting dependency loops and
| > version conflicts) are the nasty bits, that make SCM a jungle.
| >
| > |
| > | Now, if we follow the above this could hopefully still work
| > | *together*
| > | with server side solutions. For example, one approach would be:
| > |
| > | 1. Establish a minimum set of package meta data, perhaps for the
| > | package
| > | called 'MyPackage' it could be:
| > |
| > | url ->  'http://wherever/MyPackage.js'.
| > | license ->  'http://wherever/License.txt'.
| > |   "best is probably a URL to the license text or the license text
| > |   itself"
| > | author ->  'Göran Krampe<[hidden email]>'.
| > | version ->  '1.24 alpha'                    "no specific rules"
| > | dependencies ->  {'OtherPackage'. 'OneMorePackage' ->  '1.01'}
| > |
| > | 2. Build a very simple dependency resolver. If we support:
| > | a) Dependency by package name  (Amber will try to find it)
| > | b) Dependency by package URL   (Amber will simply use URL)
| > | b) Dependency with criteria    (...sky is limit here)
| > |
| >
| > Göran, this is how Metacello started:)....3 years ago ... trust
| > me... it doesn't end there:)
| >
| > I don't have the bandwidth to invent another package management
| > system:(
| >
| > My advice is to pick an existing system (javascript or
| > smalltalk-based) and adapt it to Amber. I think that a
| > javascript-based solution would give you traction with javascript
| > developers and I think that could be an important selling point...
|
| npm? it is something like a thing from a few paragraphs above - name,
| version, dependencies, file structure, ... and a cli package manager.
|
| Herby
|
| > I do plan on continuing with amber-skeleton. amber-skeleton is
| > using the current Amber client-side package model and I plan to
| > continue to follow the Amber client-side package model where-ever
| > it leads.
| >
| > |
| > | NOTE: Criteria could then be simply a string, and then we can
| > | start
| > | playing inside that string with for example ">1.01", "=1.1" or
| > | ">=1.0"
| > | and so on.
| > |
| > |
| > | Examples of optional metadata would be:
| > |
| > | source ->  'http://wherever/MyPackage.st'       "optional"
| > | homepage ->
| > |
| > | ...and so on. Now, packages can already keep the metadata
| > | described
| > | above, I built the mechanism for that. So we would just need to:
| > |
| > | - Decide on metadata (for example as above)
| > | - Add a little bit of code to make those fields easy to mess
| > | with
| > | (basically getters and setters on Package)
| > | - Add a bit of UI perhaps to set these fields :)
| > | - Write a little resolver.
| > |
| > | And the resolver should become very small since:
| > |
| > | - Packages are single files and reachable by URL.
| > | - Packages have all their metadata embedded in the file, no need
| > | for
| > | a
| > | catalog or anything.
| > |
| > | One little trick the resolve should need is that it should be
| > | able to
| > | only load the metadata (comes first in file, js or st) - so that
| > | it
| > | can
| > | find dependencies etc recursively, before it actually loads
| > | anything.
| > |
| > | Ok, so Dale, we are coming at this from two different angles -
| > | how
| > | does
| > | the above sound to you? I mean, if we agree on metadata then I
| > | can't
| > | see
| > | any harm in having different kinds of resolvers, client or server
| > | side etc.
| >
| > Göran, there are some interesting ideas in what you describe
| > above....
| >
| > However, the package model you adopt must be aimed at a specific
| > development model/system ...
| >
| > Any changes you make to the package model must be coordinated with
| > changes made to the development model ... For example, you are
| > using urls in your examples above, but you haven't specified how
| > the url will be translated to a specific file on disk or how you
| > will be differentiating urls based on versions of the packages or
| > ... In Metacello I have worked out answers to these questions and
| > others ...
| >
| > As I've said earlier, I think your best bet is to adopt/adapt an
| > existing Smalltalk or Javascript model and live with it's
| > particular quirks as a quirk-free dependency management system
| > does not exits[1]:
| >
| >    Any sufficiently advanced dependency management system is
| >    indistinguishable from Hell
| >
| > Dale
| >
| > [1] https://twitter.com/stuartsierra/status/159741771075694594
|

Dale Henrichs wrote:
> Herby,
>
> Yes, npm is a good example, if you can adapt what npm does to support
> amber-side development. Does npm have features that manage packages
> for export to the client or is it strictly for server-side package
> management?

AFAIK, npm is only about packaging: it knows how to fetch/upload
packages, where are they located, access their metadata. For the
server-side JS, it is de-facto industry standard - but in fact I don't
think it is _strictly_ server-side. It is just more convenient there,
since cli npm program is used to update packages in the file system
(what is helpful for server-side).

I see no reason why it could not be used for packaging Amber packages,
client/server agnostic. Loader must be coded, but apart from that, if
Amber uses compatible SCM that uses npm-friendly file structure (own
folder for a package, package.json in its root, otherwise whatever), it
can be reused efficiently.

npm is not SCM, just packages-on-the-net with metadata, JS version.

Herby

P.S.: Take it with 90% confidence, I do not know npm very well. Best to
ask Isaac Schlueter directly, I think (if this path is taken seriously
at least as a thought experiment).

Herby Vojčík wrote:
A little errata: I think you always do "server-side" when it comes to
placement of files you use. So if you deploy, you must create
appropriate file structure with the right packages and dependencies
(which npm can do for you), and when you develop, you probably will have
a server (local or not) which will also serve you the same structure, so
there you can use npm as well. That server-used-to-develop can have some
npm functionality in it, which when coupled with parts in IDE can give
you some of packaging functionality directly in the IDE (namely, load
and update, upload probably needs the files uploaded to some SCM/CDN
with the metadata updated, this is harder to do in Amber IDE because of
SCM/CDN part).

In other words, npm is not the option if you don't serve Amber page from
a file/folder structure (but you always do) or that structure is not
npm-friendly (which could be changed).

----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 5, 2012 11:32:50 AM
| Subject: Re: [amber-lang] Pushing Amber
|
|
|
| Dale Henrichs wrote:
| > Herby,
| >
| > Yes, npm is a good example, if you can adapt what npm does to
| > support
| > amber-side development. Does npm have features that manage packages
| > for export to the client or is it strictly for server-side package
| > management?
|
| AFAIK, npm is only about packaging: it knows how to fetch/upload
| packages, where are they located, access their metadata. For the
| server-side JS, it is de-facto industry standard - but in fact I
| don't
| think it is _strictly_ server-side. It is just more convenient there,
| since cli npm program is used to update packages in the file system
| (what is helpful for server-side).

Cool! Leveraging existing code and documentation is a real big advantage ...

|
| I see no reason why it could not be used for packaging Amber
| packages,
| client/server agnostic. Loader must be coded, but apart from that,

Then the needs of npm can drive what needs to be specified/built on the client-side ...

| if
| Amber uses compatible SCM that uses npm-friendly file structure (own
| folder for a package, package.json in its root, otherwise whatever),
| it
| can be reused efficiently.
|
| npm is not SCM, just packages-on-the-net with metadata, JS version.

This is the kind of server-side solution that I was talking about in my original message ... With amber-skeleton, I've done all of the heavy lifting on the server-side ... from the Amber-side, a request is made to load/save a particular package and the server "knows where to find/store the bits on disk."

Extra bonus points would be awarded if the Amber-side package definition/tools/web-api were common between the Node/npm and the Smalltalk/cypress solutions .... the developers would be presented with a common Amber development environment and the backend servers could be easily interchanged depending upon the server-side environment that the developer wants to use ...

Given a web-api for load/save, this should be easily doable...

Dale
 
|
| Herby
|
| P.S.: Take it with 90% confidence, I do not know npm very well. Best
| to
| ask Isaac Schlueter directly, I think (if this path is taken
| seriously
| at least as a thought experiment).
|
| > Dale
| >
| > ----- Original Message ----- | From: "Herby
| > Vojčík"<[hidden email]> | To: [hidden email] | Sent:
| > Tuesday, June 5, 2012 11:15:25 AM | Subject: Re: [amber-lang]
| > Pushing
| > Amber | | | | Dale Henrichs wrote: |>  Hey Göran... |> |>  -----
| > Original Message ----- |>  | From: "Göran
| > Krampe"<[hidden email]> |>  | To:
| > [hidden email] |>  | Sent: Monday, June 4, 2012
| > 5:27:54
| > AM |>  | Subject: Re: [amber-lang] Pushing Amber |>  | |>  | Hi
| > Dale
| > and all! |>  | |>  | On 05/31/2012 10:53 PM, Dale Henrichs wrote:
| > |>
| > |>   Göran, |>  |> |>  |>   I'll take your bait:) |>  | |>  | :) |>
| > | |>  |>   My thoughts so far have circled around the fact that the
| > |>  |>   dependencies could/should(?) be resolved on the server
| > |>  |>   side
| > ... |>  |>   no |>  |>   need for the client-code to worry about
| > package dependencies |>  |>   ... |>  |>   the server is close to
| > the
| > file system so it should do the |>  |>   heavy |>  |>   lifting ...
| > |>  |> |>  |>   If we are using Pharo/Squeak/GemStone as a server,
| > one _could_ |>  |>   use |>  |>   Metacello configurations to
| > manage
| > dependencies ... in fact it |>  |>   would be simple to manage the
| > server and client code in the |>  |>   same |>  |>
| > configuration.... |>  |> |>  |>   I'm in the middle of creating a
| > scripting API that allows one |>  |>   to |>  |>   specify a load
| > that looks like the following: |>  |> |>  |>      Metacello new |>
| > |>        project: 'STON'; |>  |>        version: '1.0'; |>  |>
| > repository: |>  |>
| > 'https://github.com/dalehenrich/ston:amber/repository'; |>  |>
| > load. |>  |> |>  |>   This code _could_ be executed in Amber on the
| > client, with the |>  |>   actual Metacello heavy lifting done on
| > the
| > server side (where |>  |>   Metacello is already running)...a load
| > list could be returned |>  |>   to |>  |>   the client and we'd be
| > off to the races .... |>  |> |>  |>   The down-side to this
| > approach
| > is that there would be a hell of |>  |>   a |>  |>   lot of work to
| > get Metacello ported to Node.js:) |>  | |>  | Mmmm, well, although
| > I
| > am all *for* any and all solutions ;) (the |>  | principle that we
| > are too few to "stifle" any initiatives) I |>  | would |>  | prefer
| > a
| > "package model" that is independent of server solution. |> |>  I'm
| > inclined to agree, but the implementation of a |>
| >  server-independent
| > model is very much complicated by the disparity |>  in the
| > supporting
| > infrastructure between Node and Pharo. |> |>  I understand your
| > desire to be "server neutral": |> |>     GemStone does not have a
| > native GUI, so we strive to |>     "client neutral", but in
| > practical
| > terms we end up |>     writing a fair amount of client-side code
| > that
| > becomes |>     tightly coupled to the client smalltalk ...
| > consequently |>     we end up doing a better job supporting some
| > clients |>     over others. |> |>  My issue with Node.js was at the
| > most basic file-system level...the |>  one thing that is missing
| > from
| > Amber (at the moment) and the one |>  thing that must exist when
| > importing exporting _files_. |> |>  So in the end, I'm afraid that
| > any client-side implementation |>  modeling will be heavily
| > influenced by the server-side support. |> |>  If you insist on
| > being
| > server-neutral, then your client-side model |>  will be limited by
| > the capabilities of the lowest common |>  denominator. |> |>  Don't
| > get me wrong, I am truly not disagreeing with this approach, |>
| >  I'm
| > just pointing out that developers with a desire for more |>
| > capabilities from the development model will be "forced to roll |>
| > their own" and for something as fundamental as the development |>
| > environment this might not be a great idea ... |> |>  I'm
| > definitely
| > not suggesting that Metacello should be used in |>  Amber
| > (Metacello
| > is solving a different set of problems) ... |>  Metacello is a
| > pragmatic choice on my part ... and will be the |>  quickest route
| > to
| > "rolling my own" dev environment for Amber ... I |>  plan using a
| > Smalltalk-based server that already supports |>  Metacello for my
| > Amber work, and with amber-skeleton, I'm well |>  along the way to
| > having an integrated server/client development |>  environment that
| > makes it real easy to share source code, the SCM |>  and package
| > management. |> |> |>  | In fact, I would list a few properties that
| > I
| > would like: |>  | |>  | 1. Independent of server tech. :) Amber is
| > already being used |>  | with |>  | non |>  | Smalltalk backends
| > etc.
| > And also with *no* backend. |> |>  Are you talking about a
| > _development environment_ that has no |>  backend? |> |>  | |>  |
| > 2.
| > Very simple. It should IMHO be limited to the very smallest |>  |
| > needed |>  | things, and not at all be aimed at the jungle of
| > source
| > code |>  | management. |> |>  Unfortunately, source code management
| > is a jungle ... side-stepping |>  source code management is an
| > option, but your developers cannot |>  side-step the issue so
| > easily,
| > they are making SCM decisions right |>  now and have to have a
| > working system ... |> |>  I'm not familiar enough with javascript
| > to
| > know whether there is a |>  well-accepted packaging model that
| > already exists for javascript |>  ... IMHO, adopting/adapting the
| > javascript model would be the best |>  choice for Amber ... |> |>
| > Reinventing the wheel is the most fun, but adapting/adopting an |>
| > existing model gets the job done... |> |>  | |>  | 3. Have a
| > working
| > dependency model. But I think it should be |>  | along |>  | the |>
| > | "works in 90% of the cases, easily overridden for the other 10%".
| > |>  | |> |>  In my experience, specifying the dependency is not the
| > hard part |>  ... resolving dependencies (finding the correct
| > versions of the |>  files), honoring the dependencies (saving the
| > files where they |>  came from) and loading the files (detecting
| > dependency loops and |>  version conflicts) are the nasty bits,
| > that
| > make SCM a jungle. |> |>  | |>  | Now, if we follow the above this
| > could hopefully still work |>  | *together* |>  | with server side
| > solutions. For example, one approach would be: |>  | |>  | 1.
| > Establish a minimum set of package meta data, perhaps for the |>  |
| > package |>  | called 'MyPackage' it could be: |>  | |>  | url ->
| > 'http://wherever/MyPackage.js'. |>  | license ->
| > 'http://wherever/License.txt'. |>  |   "best is probably a URL to
| > the
| > license text or the license text |>  |   itself" |>  | author ->
| > 'Göran Krampe<[hidden email]>'. |>  | version ->   '1.24 alpha'
| > "no specific rules" |>  | dependencies ->   {'OtherPackage'.
| > 'OneMorePackage' ->   '1.01'} |>  | |>  | 2. Build a very simple
| > dependency resolver. If we support: |>  | a) Dependency by package
| > name  (Amber will try to find it) |>  | b) Dependency by package
| > URL
| > (Amber will simply use URL) |>  | b) Dependency with criteria
| > (...sky is limit here) |>  | |> |>  Göran, this is how Metacello
| > started:)....3 years ago ... trust |>  me... it doesn't end there:)
| > |> |>  I don't have the bandwidth to invent another package
| > management |>  system:( |> |>  My advice is to pick an existing
| > system (javascript or |>  smalltalk-based) and adapt it to Amber. I
| > think that a |>  javascript-based solution would give you traction
| > with javascript |>  developers and I think that could be an
| > important
| > selling point... | | npm? it is something like a thing from a few
| > paragraphs above - name, | version, dependencies, file structure,
| > ...
| > and a cli package manager. | | Herby | |>  I do plan on continuing
| > with amber-skeleton. amber-skeleton is |>  using the current Amber
| > client-side package model and I plan to |>  continue to follow the
| > Amber client-side package model where-ever |>  it leads. |> |>  |
| > |>
| > | NOTE: Criteria could then be simply a string, and then we can |>
| > |  |
| > start |>  | playing inside that string with for example ">1.01",
| > "=1.1" or |>  | ">=1.0" |>  | and so on. |>  | |>  | |>  | Examples
| > of optional metadata would be: |>  | |>  | source ->
| > 'http://wherever/MyPackage.st'       "optional" |>  | homepage ->
| > |>
| > | |>  | ...and so on. Now, packages can already keep the metadata
| > | |>  | |>
| > | described |>  | above, I built the mechanism for that. So we
| > | would
| > just need to: |>  | |>  | - Decide on metadata (for example as
| > above) |>  | - Add a little bit of code to make those fields easy
| > to
| > mess |>  | with |>  | (basically getters and setters on Package)
| > |>
| > | - Add a bit of UI perhaps to set these fields :) |>  | - Write
| > | a
| > little resolver. |>  | |>  | And the resolver should become very
| > small since: |>  | |>  | - Packages are single files and reachable
| > by
| > URL. |>  | - Packages have all their metadata embedded in the file,
| > no need |>  | for |>  | a |>  | catalog or anything. |>  | |>  |
| > One
| > little trick the resolve should need is that it should be |>  |
| > able
| > to |>  | only load the metadata (comes first in file, js or st) -
| > so
| > that |>  | it |>  | can |>  | find dependencies etc recursively,
| > before it actually loads |>  | anything. |>  | |>  | Ok, so Dale,
| > we
| > are coming at this from two different angles - |>  | how |>  | does
| > |>  | the above sound to you? I mean, if we agree on metadata then
| > |>  | I
| > |>  | can't |>  | see |>  | any harm in having different kinds of
| > resolvers, client or server |>  | side etc. |> |>  Göran, there are
| > some interesting ideas in what you describe |>  above.... |> |>
| > However, the package model you adopt must be aimed at a specific |>
| > development model/system ... |> |>  Any changes you make to the
| > package model must be coordinated with |>  changes made to the
| > development model ... For example, you are |>  using urls in your
| > examples above, but you haven't specified how |>  the url will be
| > translated to a specific file on disk or how you |>  will be
| > differentiating urls based on versions of the packages or |>  ...
| > In
| > Metacello I have worked out answers to these questions and |>
| >  others
| > ... |> |>  As I've said earlier, I think your best bet is to
| > adopt/adapt an |>  existing Smalltalk or Javascript model and live
| > with it's |>  particular quirks as a quirk-free dependency
| > management
| > system |>  does not exits[1]: |> |>     Any sufficiently advanced
| > dependency management system is |>     indistinguishable from Hell
| > |> |>  Dale |> |>  [1]
| > https://twitter.com/stuartsierra/status/159741771075694594 |
|

On 06/05/2012 11:23 AM, Dale Henrichs wrote:
> Herby,
>
> Yes, npm is a good example, if you can adapt what npm does to support amber-side development. Does npm have features that manage packages for export to the client or is it strictly for server-side package management?
>
> Dale


I think you guys might be looking for require.js

http://requirejs.org/

Dale Henrichs wrote:
No problem with this. Just use npm-friendly file structure (own folder
with package.json, and the rest could be organized as you choose).
Herby

Paul DeBruicker wrote:
Require is for loading, but I thought the problem here is packaging.
For loading, there is of course plenty of solutions (Amber has one
loader in itself, too).

(maybe I am wrong)

Herby

----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 5, 2012 12:03:04 PM
| Subject: Re: [amber-lang] Pushing Amber
|
|
|
| Dale Henrichs wrote:
| > ----- Original Message -----
| > | From: "Herby Vojčík"<[hidden email]>
| > | To: [hidden email]
| > | Sent: Tuesday, June 5, 2012 11:32:50 AM
| > | Subject: Re: [amber-lang] Pushing Amber
| > |
| > |
| > |
| > | Dale Henrichs wrote:
| > |>  Herby,
| > |>
| > |>  Yes, npm is a good example, if you can adapt what npm does to
| > |>  support
| > |>  amber-side development. Does npm have features that manage
| > |>  packages
| > |>  for export to the client or is it strictly for server-side
| > |>  package
| > |>  management?
| > |
| > | AFAIK, npm is only about packaging: it knows how to fetch/upload
| > | packages, where are they located, access their metadata. For the
| > | server-side JS, it is de-facto industry standard - but in fact I
| > | don't
| > | think it is _strictly_ server-side. It is just more convenient
| > | there,
| > | since cli npm program is used to update packages in the file
| > | system
| > | (what is helpful for server-side).
| >
| > Cool! Leveraging existing code and documentation is a real big
| > advantage ...
| >
| > |
| > | I see no reason why it could not be used for packaging Amber
| > | packages,
| > | client/server agnostic. Loader must be coded, but apart from
| > | that,
| >
| > Then the needs of npm can drive what needs to be specified/built on
| > the client-side ...
| >
| > | if
| > | Amber uses compatible SCM that uses npm-friendly file structure
| > | (own
| > | folder for a package, package.json in its root, otherwise
| > | whatever),
| > | it
| > | can be reused efficiently.
| > |
| > | npm is not SCM, just packages-on-the-net with metadata, JS
| > | version.
| >
| > This is the kind of server-side solution that I was talking about
| > in my original message ... With amber-skeleton, I've done all of
| > the heavy lifting on the server-side ... from the Amber-side, a
| > request is made to load/save a particular package and the server
| > "knows where to find/store the bits on disk."
| >
| > Extra bonus points would be awarded if the Amber-side package
| > definition/tools/web-api were common between the Node/npm and the
| > Smalltalk/cypress solutions .... the developers would be presented
| > with a common Amber development environment and the backend
| > servers could be easily interchanged depending upon the
| > server-side environment that the developer wants to use ...
|
| No problem with this. Just use npm-friendly file structure (own
| folder
| with package.json, and the rest could be organized as you choose).

Actually, the file structure is where I expect the differences to show up... For sharing source code between Smalltalk dialects the chunk file format is not ideal ... There is a project[1] that has been running for awhile where a group of us have defined a cross dialect package format ... it is git/github friendly, but in order to get cross-dialect compatibility we've agreed upon a disk-based package format that allows us to share the source for methods, while having flexibility for different class-definition attributes (one of the places where Amber diverges from other Smalltalks as well, i.e., no class variables) and differing package implementations while making it very easy to load and share code for multiple dialects ...

I don't expect the Cypress package format[2] to be "npm-friendly" and that's why I consider it a bonus to be able to share a common web-api let alone a common disk format.

So my thoughts are that the packaging schemes and disk format of the source code on disk would differ between Node and amber-skeleton (for example), but the api for loading code into Amber could be same.

So the differences between systems do not only exist at the code level but at the disk format level and I say .... don't try to force all of the systems to conform all of the way down the format on disk ... A developer familiar with npm should not have to do anything different when using npm with Amber .... otherwise you are defeating the purpose of using npm...

The common point should be the Amber web api (this is where the Amber-specific loader kicks in)... different server implementations of the web api should be able to store the artifacts that an npm or amber-skeleton user would expect to see ...

In actuality it may not make sense to settle on a common web-api ... there may be differences in the way the loader has to interact with the client that will make it too difficult to make them conform to the same api ...

In which case we move up the abstraction level and hope for the ability to plug different package schemes into the tools...

[1] https://github.com/CampSmalltalk/Cypress
[2] https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
|
| > Given a web-api for load/save, this should be easily doable...
| >
| > Dale
| >
| > |
| > | Herby
| > |
| > | P.S.: Take it with 90% confidence, I do not know npm very well.
| > | Best
| > | to
| > | ask Isaac Schlueter directly, I think (if this path is taken
| > | seriously
| > | at least as a thought experiment).
| > |
| > |>  Dale
| > |>
| Herby
|

Dale Henrichs wrote:
But more or less, it is.
npm only needs one thing: a folder with package.json.
You have a folder per package.
So where is the problem?

> So my thoughts are that the packaging schemes and disk format of the source code on disk would differ between Node and amber-skeleton (for example), but the api for loading code into Amber could be same.

It seems to me as unnecessary complication. If it can be used as-is, why
have different things?

----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 5, 2012 1:08:12 PM
| Subject: Re: [amber-lang] Pushing Amber
|
|
|
| Dale Henrichs wrote:
| >
| > ----- Original Message -----
| > | From: "Herby Vojčík"<[hidden email]>
| > | To: [hidden email]
| > | Sent: Tuesday, June 5, 2012 12:03:04 PM
| > | Subject: Re: [amber-lang] Pushing Amber
| > |
| > |
| > |
| > | Dale Henrichs wrote:
| > |>  ----- Original Message -----
| > |>  | From: "Herby Vojčík"<[hidden email]>
| > |>  | To: [hidden email]
| > |>  | Sent: Tuesday, June 5, 2012 11:32:50 AM
| > |>  | Subject: Re: [amber-lang] Pushing Amber
| > |>  |
| > |>  |
| > |>  |
| > |>  | Dale Henrichs wrote:
| > |>  |>   Herby,
| > |>  |>
| > |>  |>   Yes, npm is a good example, if you can adapt what npm does
| > |>  |>   to
| > |>  |>   support
| > |>  |>   amber-side development. Does npm have features that manage
| > |>  |>   packages
| > |>  |>   for export to the client or is it strictly for server-side
| > |>  |>   package
| > |>  |>   management?
| > |>  |
| > |>  | AFAIK, npm is only about packaging: it knows how to
| > |>  | fetch/upload
| > |>  | packages, where are they located, access their metadata. For
| > |>  | the
| > |>  | server-side JS, it is de-facto industry standard - but in
| > |>  | fact I
| > |>  | don't
| > |>  | think it is _strictly_ server-side. It is just more
| > |>  | convenient
| > |>  | there,
| > |>  | since cli npm program is used to update packages in the file
| > |>  | system
| > |>  | (what is helpful for server-side).
| > |>
| > |>  Cool! Leveraging existing code and documentation is a real big
| > |>  advantage ...
| > |>
| > |>  |
| > |>  | I see no reason why it could not be used for packaging Amber
| > |>  | packages,
| > |>  | client/server agnostic. Loader must be coded, but apart from
| > |>  | that,
| > |>
| > |>  Then the needs of npm can drive what needs to be
| > |>  specified/built on
| > |>  the client-side ...
| > |>
| > |>  | if
| > |>  | Amber uses compatible SCM that uses npm-friendly file
| > |>  | structure
| > |>  | (own
| > |>  | folder for a package, package.json in its root, otherwise
| > |>  | whatever),
| > |>  | it
| > |>  | can be reused efficiently.
| > |>  |
| > |>  | npm is not SCM, just packages-on-the-net with metadata, JS
| > |>  | version.
| > |>
| > |>  This is the kind of server-side solution that I was talking
| > |>  about
| > |>  in my original message ... With amber-skeleton, I've done all
| > |>  of
| > |>  the heavy lifting on the server-side ... from the Amber-side, a
| > |>  request is made to load/save a particular package and the
| > |>  server
| > |>  "knows where to find/store the bits on disk."
| > |>
| > |>  Extra bonus points would be awarded if the Amber-side package
| > |>  definition/tools/web-api were common between the Node/npm and
| > |>  the
| > |>  Smalltalk/cypress solutions .... the developers would be
| > |>  presented
| > |>  with a common Amber development environment and the backend
| > |>  servers could be easily interchanged depending upon the
| > |>  server-side environment that the developer wants to use ...
| > |
| > | No problem with this. Just use npm-friendly file structure (own
| > | folder
| > | with package.json, and the rest could be organized as you
| > | choose).
| >
| > Actually, the file structure is where I expect the differences to
| > show up... For sharing source code between Smalltalk dialects the
| > chunk file format is not ideal ... There is a project[1] that has
| > been running for awhile where a group of us have defined a cross
| > dialect package format ... it is git/github friendly, but in order
| > to get cross-dialect compatibility we've agreed upon a disk-based
| > package format that allows us to share the source for methods,
| > while having flexibility for different class-definition attributes
| > (one of the places where Amber diverges from other Smalltalks as
| > well, i.e., no class variables) and differing package
| > implementations while making it very easy to load and share code
| > for multiple dialects ...
| >
| > I don't expect the Cypress package format[2] to be "npm-friendly"
| > and that's why I consider it a bonus to be able to share a common
| > web-api let alone a common disk format.
|
| But more or less, it is.
| npm only needs one thing: a folder with package.json.
| You have a folder per package.
| So where is the problem?

I assume the problem arises when you discover that a package is not a file but a directory structure itself that must be "interpreted" to create a package structure object itself.

Here's a real example[1] of two Cypress packages: Ston-Core.package and Ston-Tests.package that can be loaded into Amber using amber-skeleton. The Ston project itself[2] has branches for Pharo/Amber/GemStone versions of the same code base ... The code is stored as a method per file ...

Sooooo, I don't think that this disk format is very compatible with npm....on the other hand... it is compatible with a number of different smalltalk dialects ... so if you are interested in porting code from another Smalltalk dialect to Amber (and maintaining the port over time ... note the fork of Sven's Ston implementation which only works in Squeak and Pharo) (as I am) or interested in working with a Smalltalk server and having the amber code and server code managed in a similar project structure (as I am) then you are interested in using something like Cypress ...

amber-skeleton is not for everyone, which is why I'm suggesting that the primary development scheme for Amber be adapted from javascript and that it would be a bonus if I could seamlessly integrate something like amber-skeleton...if seamlessness cannot be achieved I would vote for javascript compatibility as the primary motivator...

Dale

[1] https://github.com/dalehenrich/ston/tree/amber/repository
[2] https://github.com/dalehenrich/ston

|
| > So my thoughts are that the packaging schemes and disk format of
| > the source code on disk would differ between Node and
| > amber-skeleton (for example), but the api for loading code into
| > Amber could be same.
|
| It seems to me as unnecessary complication. If it can be used as-is,
| why
| have different things?
|
| > So the differences between systems do not only exist at the code
| > level but at the disk format level and I say .... don't try to
| > force all of the systems to conform all of the way down the format
| > on disk ... A developer familiar with npm should not have to do
| > anything different when using npm with Amber .... otherwise you
| > are defeating the purpose of using npm...
| >
| > The common point should be the Amber web api (this is where the
| > Amber-specific loader kicks in)... different server
| > implementations of the web api should be able to store the
| > artifacts that an npm or amber-skeleton user would expect to see
| > ...
| >
| > In actuality it may not make sense to settle on a common web-api
| > ... there may be differences in the way the loader has to interact
| > with the client that will make it too difficult to make them
| > conform to the same api ...
| >
| > In which case we move up the abstraction level and hope for the
| > ability to plug different package schemes into the tools...
| >
| > [1] https://github.com/CampSmalltalk/Cypress
| > [2]
| > https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| > |
| > |>  Given a web-api for load/save, this should be easily doable...
| > |>
| > |>  Dale
| > |>
| > |>  |
| > |>  | Herby
| > |>  |
| > |>  | P.S.: Take it with 90% confidence, I do not know npm very
| > |>  | well.
| > |>  | Best
| > |>  | to
| > |>  | ask Isaac Schlueter directly, I think (if this path is taken
| > |>  | seriously
| > |>  | at least as a thought experiment).
| > |>  |
| > |>  |>   Dale
| > |>  |>
| > | Herby
| > |
|

Well, never mind.

What I am saying, whenever you have any kind of file structure where
thre is dedicated folder (and its subtree) per package, and where it's
up to you what the folder will contain and how you would use it, you can
use npm to package management. It only needs having package.json in the
root of such folder, and possibility of having all those folder
side-by-side in a one place (it may be scattered, but it is recommended
so that each project has its private copy of all its dependencies).

As an example, the Cypress file structure is very well suited for this.
It has onde folder (and its subtree) per a package, so it is very good
candidate for npm package. Yes, it is probably bloated as it contains
codes for every dialect, but npm's philosophy is "disk space is cheap"
(that's why it is recommended for each project to have its own copy of
dependent packages, it's a lot simpler than trying to DRY).

If Cypress is too much, Amber can have its own smaller package
structure: just package.json, source.st, devel.js and deploy.js under
package folder, for example.

The point is, however you choose the file structure to be, if it is
relatively fixed, you could manage packages on disk on server by npm,
and then serve them from the file system as-is to clients.

Another possibility for amber is to compile amber sources directly
inside cypress structure, but not include it in npm uploads - npm has
.npmignore file, where these build artifacts could be mentioned.

I can even see the possibility to split amber itself to smaller packages
- amber core loader (amber.js, boot.js etc.), amber cli compiler (which
can have one convenitent --all-npm option which just looks over all npm
packages, and if they contain amber st, but no js or older js, compiles
them), and then the Smalltalk packages themselves. npm will take care of
loading all necessary parts through dependencies.

IOW, decide on file structure to use and in lot of cases, you can use
npm to package-manage it. If you select the file structure to be
well-known, you can use the files as-is, without special server-side
processing. Things outside package management are npm agnostic and you
should solve them otherwise (SCM).

Herby

Dale Henrichs wrote:

On Wednesday, May 30, 2012 4:47:23 PM UTC+2, nicolas petton wrote:

- Pragmas?

Herby Vojčík wrote:
OK, so I have looked at npm more in-depth and I must say I
oversimplified some things - it is not the exactly right solution -
mainly because it stores dependencies inside package, creating tree of
dependencies, but not including them if they already are upper - relying
on the fact the node's require will process the file structure, so they
are not usable as-is (they need server-side processing, at least when
looking for them).

But maybe there can be inspiration or reusing something similar.

Herby

Herby,

I clearly don't understand npm and that's kinda my point ... for folks using Node as the Amber server, npm makes a ton of sense to use for managing package dependencies ... for folks using Smalltalk as the Amber server, npm won't do them much good ...

If the directory structure can be the same that is a definite plus ...


----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 2:53:43 AM
| Subject: Re: [amber-lang] Pushing Amber
|
| Well, never mind.
|
| What I am saying, whenever you have any kind of file structure where
| thre is dedicated folder (and its subtree) per package, and where
| it's
| up to you what the folder will contain and how you would use it, you
| can
| use npm to package management. It only needs having package.json in
| the
| root of such folder, and possibility of having all those folder
| side-by-side in a one place (it may be scattered, but it is
| recommended
| so that each project has its private copy of all its dependencies).

I clearly don't have a good picture of what services npm provides...

|
| As an example, the Cypress file structure is very well suited for
| this.
| It has onde folder (and its subtree) per a package, so it is very
| good
| candidate for npm package. Yes, it is probably bloated as it contains
| codes for every dialect, but npm's philosophy is "disk space is
| cheap"

The code for every dialect is managed on separate code branches in git ... so for a given checkout on a dialect branch the code that is present only applies to that dialect ...

| (that's why it is recommended for each project to have its own copy
| of
| dependent packages, it's a lot simpler than trying to DRY).

Yeah, I understand the bit about disk space being cheap, but when it comes to copying source code around that kinda bothers me ... but copying definitely makes it easier for the package manager:)
 
|
| If Cypress is too much, Amber can have its own smaller package
| structure: just package.json, source.st, devel.js and deploy.js under
| package folder, for example.
|
| The point is, however you choose the file structure to be, if it is
| relatively fixed, you could manage packages on disk on server by npm,
| and then serve them from the file system as-is to clients.

Yeah, Cypress isn't intended to be the primary format for every dialect to use ... Cypress is intended to be the mechanism for sharing source code between dialects ... I happen to do the bulk of my work spanning multiple Smalltalk dialects and prefer to use it because it is convenient ...

So I stress that as Amber develops it's package structure it should be designed to meet the needs of the primary development model ...

|
| Another possibility for amber is to compile amber sources directly
| inside cypress structure, but not include it in npm uploads - npm has
| .npmignore file, where these build artifacts could be mentioned.
|
| I can even see the possibility to split amber itself to smaller
| packages
| - amber core loader (amber.js, boot.js etc.), amber cli compiler
| (which
| can have one convenitent --all-npm option which just looks over all
| npm
| packages, and if they contain amber st, but no js or older js,
| compiles
| them), and then the Smalltalk packages themselves. npm will take care
| of
| loading all necessary parts through dependencies.
|
| IOW, decide on file structure to use and in lot of cases, you can use
| npm to package-manage it. If you select the file structure to be
| well-known, you can use the files as-is, without special server-side
| processing. Things outside package management are npm agnostic and
| you
| should solve them otherwise (SCM).
|
| Herby
|
| Dale Henrichs wrote:
| >
| > ----- Original Message -----
| > | From: "Herby Vojčík"<[hidden email]>
| > | To: [hidden email]
| > | Sent: Tuesday, June 5, 2012 1:08:12 PM
| > | Subject: Re: [amber-lang] Pushing Amber
| > |
| > |
| > |
| > | Dale Henrichs wrote:
| > |>
| > |>  ----- Original Message -----
| > |>  | From: "Herby Vojčík"<[hidden email]>
| > |>  | To: [hidden email]
| > |>  | Sent: Tuesday, June 5, 2012 12:03:04 PM
| > |>  | Subject: Re: [amber-lang] Pushing Amber
| > |>  |
| > |>  |
| > |>  |
| > |>  | Dale Henrichs wrote:
| > |>  |>   ----- Original Message -----
| > |>  |>   | From: "Herby Vojčík"<[hidden email]>
| > |>  |>   | To: [hidden email]
| > |>  |>   | Sent: Tuesday, June 5, 2012 11:32:50 AM
| > |>  |>   | Subject: Re: [amber-lang] Pushing Amber
| > |>  |>   |
| > |>  |>   |
| > |>  |>   |
| > |>  |>   | Dale Henrichs wrote:
| > |>  |>   |>    Herby,
| > |>  |>   |>
| > |>  |>   |>    Yes, npm is a good example, if you can adapt what
| > |>  |>   |>    npm does
| > |>  |>   |>    to
| > |>  |>   |>    support
| > |>  |>   |>    amber-side development. Does npm have features that
| > |>  |>   |>    manage
| > |>  |>   |>    packages
| > |>  |>   |>    for export to the client or is it strictly for
| > |>  |>   |>    server-side
| > |>  |>   |>    package
| > |>  |>   |>    management?
| > |>  |>   |
| > |>  |>   | AFAIK, npm is only about packaging: it knows how to
| > |>  |>   | fetch/upload
| > |>  |>   | packages, where are they located, access their metadata.
| > |>  |>   | For
| > |>  |>   | the
| > |>  |>   | server-side JS, it is de-facto industry standard - but
| > |>  |>   | in
| > |>  |>   | fact I
| > |>  |>   | don't
| > |>  |>   | think it is _strictly_ server-side. It is just more
| > |>  |>   | convenient
| > |>  |>   | there,
| > |>  |>   | since cli npm program is used to update packages in the
| > |>  |>   | file
| > |>  |>   | system
| > |>  |>   | (what is helpful for server-side).
| > |>  |>
| > |>  |>   Cool! Leveraging existing code and documentation is a real
| > |>  |>   big
| > |>  |>   advantage ...
| > |>  |>
| > |>  |>   |
| > |>  |>   | I see no reason why it could not be used for packaging
| > |>  |>   | Amber
| > |>  |>   | packages,
| > |>  |>   | client/server agnostic. Loader must be coded, but apart
| > |>  |>   | from
| > |>  |>   | that,
| > |>  |>
| > |>  |>   Then the needs of npm can drive what needs to be
| > |>  |>   specified/built on
| > |>  |>   the client-side ...
| > |>  |>
| > |>  |>   | if
| > |>  |>   | Amber uses compatible SCM that uses npm-friendly file
| > |>  |>   | structure
| > |>  |>   | (own
| > |>  |>   | folder for a package, package.json in its root,
| > |>  |>   | otherwise
| > |>  |>   | whatever),
| > |>  |>   | it
| > |>  |>   | can be reused efficiently.
| > |>  |>   |
| > |>  |>   | npm is not SCM, just packages-on-the-net with metadata,
| > |>  |>   | JS
| > |>  |>   | version.
| > |>  |>
| > |>  |>   This is the kind of server-side solution that I was
| > |>  |>   talking
| > |>  |>   about
| > |>  |>   in my original message ... With amber-skeleton, I've done
| > |>  |>   all
| > |>  |>   of
| > |>  |>   the heavy lifting on the server-side ... from the
| > |>  |>   Amber-side, a
| > |>  |>   request is made to load/save a particular package and the
| > |>  |>   server
| > |>  |>   "knows where to find/store the bits on disk."
| > |>  |>
| > |>  |>   Extra bonus points would be awarded if the Amber-side
| > |>  |>   package
| > |>  |>   definition/tools/web-api were common between the Node/npm
| > |>  |>   and
| > |>  |>   the
| > |>  |>   Smalltalk/cypress solutions .... the developers would be
| > |>  |>   presented
| > |>  |>   with a common Amber development environment and the
| > |>  |>   backend
| > |>  |>   servers could be easily interchanged depending upon the
| > |>  |>   server-side environment that the developer wants to use
| > |>  |>   ...
| > |>  |
| > |>  | No problem with this. Just use npm-friendly file structure
| > |>  | (own
| > |>  | folder
| > |>  | with package.json, and the rest could be organized as you
| > |>  | choose).
| > |>
| > |>  Actually, the file structure is where I expect the differences
| > |>  to
| > |>  show up... For sharing source code between Smalltalk dialects
| > |>  the
| > |>  chunk file format is not ideal ... There is a project[1] that
| > |>  has
| > |>  been running for awhile where a group of us have defined a
| > |>  cross
| > |>  dialect package format ... it is git/github friendly, but in
| > |>  order
| > |>  to get cross-dialect compatibility we've agreed upon a
| > |>  disk-based
| > |>  package format that allows us to share the source for methods,
| > |>  while having flexibility for different class-definition
| > |>  attributes
| > |>  (one of the places where Amber diverges from other Smalltalks
| > |>  as
| > |>  well, i.e., no class variables) and differing package
| > |>  implementations while making it very easy to load and share
| > |>  code
| > |>  for multiple dialects ...
| > |>
| > |>  I don't expect the Cypress package format[2] to be
| > |>  "npm-friendly"
| > |>  and that's why I consider it a bonus to be able to share a
| > |>  common
| > |>  web-api let alone a common disk format.
| > |
| > | But more or less, it is.
| > | npm only needs one thing: a folder with package.json.
| > | You have a folder per package.
| > | So where is the problem?
| >
| > I assume the problem arises when you discover that a package is not
| > a file but a directory structure itself that must be "interpreted"
| > to create a package structure object itself.
| >
| > Here's a real example[1] of two Cypress packages: Ston-Core.package
| > and Ston-Tests.package that can be loaded into Amber using
| > amber-skeleton. The Ston project itself[2] has branches for
| > Pharo/Amber/GemStone versions of the same code base ... The code
| > is stored as a method per file ...
| >
| > Sooooo, I don't think that this disk format is very compatible with
| > npm....on the other hand... it is compatible with a number of
| > different smalltalk dialects ... so if you are interested in
| > porting code from another Smalltalk dialect to Amber (and
| > maintaining the port over time ... note the fork of Sven's Ston
| > implementation which only works in Squeak and Pharo) (as I am) or
| > interested in working with a Smalltalk server and having the amber
| > code and server code managed in a similar project structure (as I
| > am) then you are interested in using something like Cypress ...
| >
| > amber-skeleton is not for everyone, which is why I'm suggesting
| > that the primary development scheme for Amber be adapted from
| > javascript and that it would be a bonus if I could seamlessly
| > integrate something like amber-skeleton...if seamlessness cannot
| > be achieved I would vote for javascript compatibility as the
| > primary motivator...
| >
| > Dale
| >
| > [1] https://github.com/dalehenrich/ston/tree/amber/repository
| > [2] https://github.com/dalehenrich/ston
| >
| > |
| > |>  So my thoughts are that the packaging schemes and disk format
| > |>  of
| > |>  the source code on disk would differ between Node and
| > |>  amber-skeleton (for example), but the api for loading code into
| > |>  Amber could be same.
| > |
| > | It seems to me as unnecessary complication. If it can be used
| > | as-is,
| > | why
| > | have different things?
| > |
| > |>  So the differences between systems do not only exist at the
| > |>  code
| > |>  level but at the disk format level and I say .... don't try to
| > |>  force all of the systems to conform all of the way down the
| > |>  format
| > |>  on disk ... A developer familiar with npm should not have to do
| > |>  anything different when using npm with Amber .... otherwise you
| > |>  are defeating the purpose of using npm...
| > |>
| > |>  The common point should be the Amber web api (this is where the
| > |>  Amber-specific loader kicks in)... different server
| > |>  implementations of the web api should be able to store the
| > |>  artifacts that an npm or amber-skeleton user would expect to
| > |>  see
| > |>  ...
| > |>
| > |>  In actuality it may not make sense to settle on a common
| > |>  web-api
| > |>  ... there may be differences in the way the loader has to
| > |>  interact
| > |>  with the client that will make it too difficult to make them
| > |>  conform to the same api ...
| > |>
| > |>  In which case we move up the abstraction level and hope for the
| > |>  ability to plug different package schemes into the tools...
| > |>
| > |>  [1] https://github.com/CampSmalltalk/Cypress
| > |>  [2]
| > |>  https://github.com/CampSmalltalk/Cypress/blob/master/img/CypressStructure-STIC2012.png
| > |>  |
| > |>  |>   Given a web-api for load/save, this should be easily
| > |>  |>   doable...
| > |>  |>
| > |>  |>   Dale
| > |>  |>
| > |>  |>   |
| > |>  |>   | Herby
| > |>  |>   |
| > |>  |>   | P.S.: Take it with 90% confidence, I do not know npm
| > |>  |>   | very
| > |>  |>   | well.
| > |>  |>   | Best
| > |>  |>   | to
| > |>  |>   | ask Isaac Schlueter directly, I think (if this path is
| > |>  |>   | taken
| > |>  |>   | seriously
| > |>  |>   | at least as a thought experiment).
| > |>  |>   |
| > |>  |>   |>    Dale
| > |>  |>   |>
| > |>  | Herby
| > |>  |
| > |
|

----- Original Message -----
| From: "Herby Vojčík" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 3:47:55 AM
| Subject: Re: [amber-lang] Pushing Amber
|

|
| OK, so I have looked at npm more in-depth and I must say I
| oversimplified some things - it is not the exactly right solution -
| mainly because it stores dependencies inside package, creating tree
| of
| dependencies, but not including them if they already are upper -
| relying
| on the fact the node's require will process the file structure, so
| they
| are not usable as-is (they need server-side processing, at least when
| looking for them).
|
| But maybe there can be inspiration or reusing something similar.
|
| Herby

Herby,

Ah, so there'd need to be special-case code to adapt it for client-side use then:(

If you are going to add dependencies to Amber packages, there are a number of moving parts that need to be coordinated ... disk format, package manager, dependency resolver and loader ...

Dale