Splitting into separate apps

[XaviP]

Collecting info about ways to separate an app into several.

As a first step, models.py and views.py can be splitted into separate files. This can be an improvement to avoid merge problems, if different developers works in the same app. Can be better for document each model and view too. Maybe this can be a good idea for valuenetwork/valueaccounting/models.py (12k lines) and valuenetwork/valueaccounting/views.py (13k lines) as this app is like the core of the project, so no need to separate it in different apps (not sure, please correct me):

• How to split models.py into separate files?
• Breaking Apart Models in Django
• How to Split Views Into Multiple Files

[bum2]

@bum2 do you have an estimate on when this release that includes the general app will be ready? It also needs to be tested by FC admin people, who show no sign of testing it. Even enough to discuss if they agree it is a requirement.

That depends not only of my roadmap but also of the missing testing and feedback from coop admins or project coordinators, so i'm developing kind of blind, and just me and sometimes @fosterlynn are testing things. By the way, my roadmap is + o - at https://github.com/FreedomCoop/valuenetwork/issues/184 but also other things happen around in other sites (and a pending huge migration) and is hard to find enough concentration on ocp...

[XaviP]

Just some questions: this General app is a separate app from the "core" app, right? Can we focus in this issue about the way we are going to refactor the core? Or do we need to discuss if this app goes into the core? Is this the goal of all this chat? Sorry to not understand all concepts you are talking about.

[ghost]

Just some questions: this General app is a separate app from the "core" app, right?

Yep. IMHO I would refactor first valueaccounting to make it as generic as possible so apps as general can derive its classes with minimum effort.

BTW, I created an organization called django-rea on which to host the artifacts of the refactor. @bhaugen will be the owner once he accepts the invitation, and of course, if he agrees :)

[bhaugen]

BTW, I created an organization called django-rea on which to host the artifacts of the refactor. @bhaugen will be the owner once he accepts the invitation, and of course, if he agrees :)

Accepted invitation. Can we have more owners? I am not enough.

[ghost]

Yep, as many as you want. I made you already owner. In your profile settings there's a tab at the bottom where you can manage the organization.

[fosterlynn]

That depends not only of my roadmap but also of the missing testing and feedback from coop admins or project coordinators, so i'm developing kind of blind,

Yes, that is a difficult way to develop. :disappointed: But it looks like the reality for the moment, as you and others have requested help testing with no answer.

and is hard to find enough concentration on ocp...

Given all of this, I think we should go ahead without this branch, and get to the minimum joint repo in the simplest way possible.

What do others think?

[bhaugen]

I had gotten the impression that nobody was ready to use the project features in OCP yet, but apparently this might change in this upcoming hackathon in Athens. @XaviP @bum2 are you going?

[bhaugen]

Let's move the General app discussion over to #206 Ok? @bum2 has provided some documents to study, including one about how it's integrated into OCP.

This is not a comment about whether that branch, and the General app, should be included in the first drop of a repo to refactor.

[XaviP]

Let's move the refactoring discussion to django-rea/rea-project#1