Goals of refactoring?

[bhaugen]

What are we trying to accomplish? Our goals might affect how we do it.

In #1 I listed some of these, but nobody has responded, so I'm trying again.

I can think of several goals for refactoring:

• smaller and less intimidating models files.
• separating into units of work: that is, groups of model classes that somebody might work on together, that might be logically connected in features.
• separating out a core that everybody can use and improve, so less work is going into different forks.
• separating into modules that one or other group might want to use, or not use (which might be done better by separating into apps than just models files).
• separating into components which somebody might want to override with their version of the same component.
• other goals? I am sure I have not thought of everything.

[XaviP]

other goals?

• The "community of users" (current forks) can decide that one improvement made in a app (current fork) is an interesting feature for all of them, so we can incorporate it in the next django-rea package release, with backwards compatibility.

[fosterlynn]

separating out a core that everybody can use and improve, so less work is going into different forks.

This seems like the key one to me. (Some of the rest are connected to this.)

separating into modules that one or other group might want to use, or not use (which might be done better by separating into apps than just models files)

This one also so that groups can use each other's features, rather than forking permanently, keep it all together.

If we can get away from permanent forks, and just have a bunch of available apps, some overlapping, that seems ideal. (note the source, me, not nearly as technical as the rest of you :) )

A note on my division of classes: This also took into account a secondary goal of having it split up in ways that the whole core does not have to be implemented if a group wants to implement a portion of core NRP. (like Chris Troutner's rasberry pi OVN)

[bhaugen]

Does separating out a core require separating into apps, not just files as in a models directory?

[XaviP]

If we can get away from permanent forks, and just have a bunch of available apps, some overlapping, that seems ideal.

I agree. I have used the word "forks" because it's the current implementation. I've edited the comment in this sense.

Does separating out a core require separating into apps, not just files as in a models directory?

I don't think so (but not sure), specially if we decide to make the core with ABCs. Each app (current fork) will be able to decide which classes to use.

[ghost]

Does separating out a core require separating into apps, not just files as in a models directory?

Imho, the apps structure is a Django construct similar to Python packages, but towards a set of defined components: models, views and tests primarily. If we can separate the responsibilities into apps, it could be, I think, more Pythonic, and especially Djangonic. What I think we might not need to do by now is to separate the django_rea namespace under different pypi dependencies. As Django does, we'd only have django_rea as a pypi dependency, and then, the forks, or implementors, could have their own Django stuff (wsgi.py, settings.py, etc.)

I can imagine an agenda as the following, but I am surely missing lots of other steps in the process, but something like as follows:

1. separate models into @fosterlynn convention.
2. upgrade to Django 1.9.
3. make key models (especially those involved with faircoins), ABC classes, this involves as well implementing in OCP the default classes and moving the faircoin functionality into their realm.
4. create a new folder for DEEP mostly a clone of OCP. move the work app into a django_rea.contrib.work package.
5. refactor views into Django generic class views and make use of more REST alike url conventions.
6. split everything into apps.
7. upgrade dependencies (bootstrap theme, django, etc.)
8. start a new repository called django_rea in which only django_rea will reside, and on which everything will be worked on by consensus of the different implementors.

This was my hidden agenda. I might be writing this too task driven, but I am quite new to the project so I can't contribute at the moment from previous experience :/

[bhaugen]

One reason for apps as optional modules is that you can select and deselect in settings.INSTALLED_APPS and in requirements.txt.

[fosterlynn]

moving the faircoin functionality into their realm.

Notes fyi: Matrioshka (Sensorica) is thinking they may want the FairCoin stuff. Also, OCP is doing a hackathon in March where they will add some kind of bank interface in addition to FairCoin interface. All of that says to me we need to make currency connections easily configurable.

[bhaugen]

One more thing about apps and settings and requirements: it is common for each app to have its own settings and requirements. I have not done the per-app settings myself, but fobi, used by OCP, has its own settings:
https://github.com/barseghyanartur/django-fobi/tree/master/src/fobi

[ghost]

it is common for each app to have its own settings and requirements

We would need to make django_rea a python egg with its setup.py and setup.cfg files and everything in between :) I think django-fobi provides some good defaults.

I have not done the per-app settings myself, but fobi, used by OCP, has its own settings

If I am not mistaken that's so you can import some defaults into your installation settings.py file. For instance they don't define database backends but a few constants. In django_rea it will make sense for some apps, yep.

[bhaugen]

I'm trying to figure out how to change a main settings.py and requirements.txt without forking the core repo.

Maybe by the core repo not having the main settings.py and requirements.txt at all? Maybe those can be a project repo for each configured system, e.g. OCP, DEEP, etc.?

[ghost]

Yep, each configured system could have those files in a custom repo.