Thanks for reminding, Evgeny! 
[Hope people which managed to miss return statement will not miss these series :) ]

Threading is a god send in very populated forums. You could used to flat discussions if there are no many participants, but once more people got involved, and more topics got added to the fule, the harder to navigate in a flat thread. 

Threading might be not that deep (i.e. a couple of "em" to the right), but in either form they better to keep threading.

[Lack of threading is driving me crazy in all modern messengers with groups enabled, like Slack, Skype, Telegram. Have you ever tried to not get lost in very popular chat room in Telegram or Slack once there are more than 500 members joined?]

1. When authorization will be implemented - you could go and proceed it yourself;

2. but at the moment (curated mode) - one could ask me to be added to the list via GitHub issue (or via email, if you know my address, and you do :) )

Hopefully 1 will become possible relatively soon, so 2 will not stand for too long.

Indeed, but I'm reluctant to remove it, at leats now, but rather use as a good corner case of system version dependency. We should declare it as Caché 2014-2015 only, (or rather declaratively  <=2015.*).

Certainly, as original author, you have full rights to unpublish it, if you want to. But please wait till we resolve all authorization issues (or make it using GitHub SSO).


Have I already mentioned it yet, that the lowest Caché version which I want to have CPM working is 2014.1? (where CSP.REST support introduced). Soe there are 2 major versions (2014 and 2015) where this component makes a lot of sense.

And these 2 silly projects named 'tsafin~*' were put to the list just for this particular reason: I need to have a few components in the registry over which I have direct control, and where I could put such versioning information in the format expected by CPM


At the times when I was one of admins in both "intersystems" and "intersystems-ru" GitHub repositories I could just go and commit the correct version support. :) But right now I could not be so rude anymore, and need to play by rules, be gentlemen and ask for a favor.

[Ok, that was a joke - I've never intended to be so much rude]

Well, you remember, this is still "curated" list? So any kbit of information I put to repository have been verified (created) by me. Originally, version information is coming from GitHub metadata for a given project. If this project did have releases (like webterminal) then version is there and I use it inside, if there were no releases, then I put default version number 0.0.1 (npm is rejecting packages without version triplet).

After a moment community would start to use "package.json inside of class xdata" trick, since then we would have version information as precise as author wanted (and XData information will override release matadata values, so it will be author responsibility to keep them updated).

We could try to use automatically generated XData package definitions for each imported github repo, but they will work only if they have been committed to the original source repository. So it still needs some cooperation with author.


It wil be much, much easier, if eventually Cache (somehoow) would get native package.json (or generic *.json, or *.yml) support in the class compiler...

Well, this is interesting aspect we did discuss internally. But from practical point of view (intending to create working system the simplest way possible) it was easier for us to start from the system where modern ObjectScript and rich classes library were available. It's just thousands times easier than without them.

Let see how far we could get with ObjectScript part of story, we should first get some developer attention, fill repository, grow audience...


And there is no need to name it CMPM if there would be some MUMPS, because the first "C" means "Community" today :)

[Did you see that nice animation I've inserted to the CPM cover page? That was done for a reason]

Yes, proper dependency tracking is tough. And some modern package managers allow to "lock" versions you have downloaded and stick with them forever. I do not see a way how multiple versions of a same component could be used in the same namespace, but, on the other hand, for local installations it's pretty easy to have multiple versions installed in the different namespaces. And developer could then lock some versions for selecte namespaces/applications.

In any case corner cases here are multiple, that's why we decided to postpone implementation of dependency tracking till later releases.