grumpyinca
commented
4 years ago Today's conversation touched on these web pages:
NPM - Creating and publishing private packages
Also, we developed the notion that cloning a repository is less effort than working through how to work with packages. Even so, there is a need for developing a few test cases before attempting this at full scale on the first day.
As written, this issue is not "well formed" in that it does not (yet) have a clear correspondence to specific code changes. Perhaps it would be better handled as a docs/design article.
Perhaps this issue & branch can contain experimental and prototype work on the subject. Other, more well formed issues can follow from there.
Case 1:
In the future, it may become desirable to easily generate and support multiple "private-label" versions of the same underlying code. Specifically, different spring manufacturers may want to have have their websites link to what is currently called ODOP:Spring but have the name and logo of the software appear to be unique to that manufacturer.
With respect to the app itself, the necessary changes might be relatively straight forward. For example an environment variable could point to a unique logo. Similarly, other variables could point to text for the manufacturer name, program name or fixed report content. This approach might require a different instance on Heroku for each different private label version. Alternatively, if possible to specify the private-label version by passing a parameter as part of the URL that loads the software, perhaps only one Heroku instance would be required.
With respect to the documentation (on-line Help) and its embedded screenshots, the necessary changes to create multiple private versions will likely be a bigger challenge.
Case 2: Other organizations may be interested in incorporating an open source ODOP into a proprietary product, for example, a spring design package that has proprietary equations, material properties and catalogs.
What are the costs & benefits associated with breaking up the ODOP repository into three (now) or more (future) separate repos ? Specifically:
Perhaps links could be used to deal with the fragmentation of the docs. It is less certain on how updates to the base ODOP code could flow into apps built on it. Would such an approach turn into a code management nightmare ? Do NPM or GitHub "packages" have a role here ?