-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
Answers below...
Le 26/01/2015 10:40, Houtan a écrit :
Hello,
If I should have any spare time this week, I wanted to work on https://github.com/DynareTeam/dynare/issues/811.
Looking into this has brought up several questions. If I understand correctly, the idea of moving dates and dseries into their own repositories was that they can be used as standalone programs. As such, we want to permit people who can benefit from this code to use it directly instead of having to download Dynare as a whole. In essence, we're treating them as libraries, which I think is a good idea.
Initially the idea was to make these codes available without downloading the whole Dynare. But I did not intend to produce standalone programs. For me it's not a problem if the dseries package requires another package (dates package in this case). I do not like the idea of having dates as a submodule of dseries, or dates and dseries as submodules of reporting, ... I do not see any advantage here, only more work.
But, as it's setup now, dseries is not a standalone program. In order to make it a standalone program, we'd need to add dates as a submodule of this program and probably have a configuration script that adds the dates repository to the Matlab/Octave path. At least, that's how I'd like to set up reporting: add dates and dseries as submodules to reporting so that someone could clone the reporting repository, initialize its submodules and use it as a standalone program.
We just need to explain that if one wants to use the reporting module, then the dates and dseries modules must be in the Matlab/Octave's path. We can also provide a script to install these modules (but we do not need git to do that).
Doing so would not present a problem to Dynare users as Dynare could still include a dates submodule, a dseries submodule that contains a dates submodule, and a reporting submodule that contains both a dseries and dates submodule. As long as the git clone or the git submodule init are not issued with the --recursive switch, the nested submodules will not be brought in and hence the code will not be duplicated.
Furthermore, I think we should discuss the location of submodules within Dynare. Currently, they're in several places:
- contrib 2) matlab/utilities/tests 3) matlab/modules
This is confusing. Though I don't have a strong opinion as to the logic we should impose on the submodules we include, I believe there should be a logic. Should all external submodules be included in contrib? should all internal matlab submodules be included in matlab/modules? Should all matlab tests be included in tests/modules (matlab/utilities/tests has to be changed, in my opinion)? It would be nice if we could make a decision about the organization of the submodules within Dynare as a group so that, going forward, we have a coherent structure that does not evolve organically but rather in an organized and logical way.
I plan to put the tests routines under matlab/modules. I think that we should have only two locations. The logic being that some codes are supported/produced by us, in modules folder for instance, and other codes are not produced/supported by us (we do not ensure that these codes will work in future versions of Dynare), in a contribs folder.
Best, Stéphane.
Best, Houtan _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
- -- Stéphane Adjemian Université du Maine, Dynare Team