Common classes with JSON library representation
I agree a common package manager for Omnis makes sense, and I see the ecosystem starting to head that direction. The good news is that many others have beaten down this path for us already and we can follow their lead for what works and what doesn’t.
While I also agree that completely decoupling the front-end from the back-end is a challenge, I feel a well-versioned API can solve this. Adopting true semantic versioning only works if developers are strict about it. but it does work when they do.
Alex
> On Oct 23, 2017, at 14:34, Clifford Ilkay <cilkay@gmail.com> wrote:
>
> Hello,
>
> I have attempted to use git submodules on our AngularJS/Node.js application
> and gave up on it because of the potential for problems and how cumbersome
> it was to use. The problems with submodules are well-documented all over
> the Internet. One such example is here: <
> codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/>.
> I would advise you to heed those who tell you to stay away from them and if
> you must, look at one of the alternative approaches.
>
> We used to have two separate repos for frontend and backend and
> theoretically, they were independent of each other. There were two problems
> with that approach. First, a coherent release consists of a particular
> changeset of the frontend with a particular changeset of the backend.
> Complete separation of frontend and backend is a myth even if the frontend
> only interacts with the backend via a RESTful interface. When the model
> changes in the backend and new API endpoints are exposed, an older version
> of the frontend will not even know of the existence of those endpoints,
> much less be able to do anything with them.
>
> Second, there are very good reasons to share code between the frontend and
> backend. We have data validation classes that both the frontend and backend
> use, for example.
>
> Our solution was to combine the frontend and backend repos into one repo.
> That is probably not appropriate for you.
>
> What you are pointing to is an architectural issue, that is, the lack of
> any coherent module/packages system for Omnis. Node.js has npm modules <
> docs.npmjs.com/>. Python has modules which are packaged <
> packaging.python.org/>. Django created applications <
> docs.djangoproject.com/en/dev/intro/reusable-apps/>, which enable
> one to “plug in” code written by others with minimal fuss into your Django
> projects. The solution to this issue is not to come up with better revision
> control tools to work around the lack of any well-defined method of
> interfacing “foreign” code into your Omnis libraries. It’s to create a
> well-documented and well-defined interface mechanism for Omnis. That
> well-defined and well-documented interface very well might be a library.
> However, if I had a bunch of Omnis libraries, mine and others, how would I
> know which changesets/versions constitute a coherent release?
>
> In Python, we can capture which modules at what versions are being used in
> a particular environment into a text file, requirements.txt, which is only
> called that by convention, not by any hard rule. Here is an excerpt from
> one of my projects.
>
> asgi-redis==0.14.1
> asgiref==0.14.0
> autobahn==0.16.0
>
> In that particular project, there are 38 lines in requirements.txt. That
> file is kept under revision control. Implicit in that statement is the
> requirements.txt can change over time. I can re-create that project exactly
> as it was at a particular changeset by using the Python package installer,
> pip, by doing: “pip install -r requirements.txt”.
>
> Node.js has a similar mechanism, package.json, which I think is even more
> sophisticated. We can specify production or development only dependencies,
> and various scripts to test, deploy, and run the application in this file.
> Again, that is kept under revision control.
>
> Omnis doesn’t have anything like this so if you really want to deal with
> this issue, that is the place to start. Agree on a mechanism, ideally
> something that can be automated with a script (use OmnisCLI – hint, hint),
> that would enable someone to take your package.json, execute “om install
> package.json” and assuming that all the requirements within package.json
> are somewhere on the network, whether local or on the Internet, you can
> reconstitute that Omnis application. A specification, implementation, and
> documentation of Omnis library packaging is a necessary but insufficient
> condition for making all this work. You’ll still need a package directory
> that can be explored. You can’t just say, “look for the Omnis tag on
> GitHub”.
>
> Regards,
>
> Clifford Ilkay
>
> + 1 647-778-8696
>
> On Mon, Oct 23, 2017 at 11:55 AM, Alex Clay <aclay@mac.com> wrote:
>
>> Hi Graham,
>>
>> Associated classes are our biggest sticking point for moving to git. There
>> are a couple solutions I’ve come up with so far:
>>
>> 1) Move this code to a separate Omnis library
>> 2) Use a git submodule, which lets you merge multiple repositories
>> together into a single working copy
>>
>> We’re proceeding with option 1, mostly by moving the project-specific
>> classes to separate libraries and leaving the rest in a single core library.
>>
>> Using submodules would work in theory, but it’s more complicated. The
>> workflow would be:
>>
>> 1) Create a repository for your common code
>> 2) Include this repository in your project as a submodule
>> 3) Export your lib to JSON
>> 4) Copy the common classes into the directory for the common submodule
>> 5) Commit and push your changes
>>
>> When building out, you would pull remote updates, then copy the common
>> code back into the JSON source for your library. Rebuilt the lbs from the
>> repository and you should be good to go.
>>
>> The trick is identifying which classes are common and which aren’t. This
>> is one reason we’re just going to split up the project—this identification
>> is easy to express by dividing classes into libraries.
>>
>> I’ll make a caveat that this is all theoretical—I haven’t tried using the
>> submodules to see if there is a better solution. If someone does find a
>> good way to express the Omnis VCS’ concept of associations in git, please
>> share!
>>
>> Alex
>>
>>> On Oct 23, 2017, at 11:41, Graham Stevens <graham.stevens@gmail.com>
>> wrote:
>>>
>>> Hi $all,
>>>
>>> I realize this question is probably a bit early as most of us aren’t yet
>> using the new JSON library export but I’ll ask it anyway. I probably
>> should have brought it up at EurOmnis but it has only just occurred to me
>> now I am back in the office.
>>>
>>> Has anybody put thought into a satisfactory way to handle classes which
>> are common to more than one library/application? We have multiple
>> applications and an infrastructure library of common code in our Omnis
>> VCS. This library’s classes are linked to most of our applications and
>> this works very well in the context of building our libraries from the
>> VCS. But I don’t immediately see an obvious way to handle this in a
>> multiple repository setup like Git. It may just be that I don’t yet have a
>> full understanding of Git but I would appreciate any thoughts you may have
>> on the topic.
>>>
>>> Thanks and best regards,
>>> Graham
>>>
>>> PS. It was great to see and catch up with everyone at the conference.
>>> _____________________________________________________________
>>> Manage your list subscriptions at lists.omnis-dev.com
>>
>> _____________________________________________________________
>> Manage your list subscriptions at lists.omnis-dev.com
>>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
