lør, 25 07 2009 kl. 07:19 -0500, skrev Carlo de Falco: > Thinking a bit more about it, > one argument in favour of having data in "inst/data" is that it > doesn't require any change to pkg.m as any subdirectory of "inst" will > be copied to the package installation location so to > make this change only the documentation would need to be changed...
That is a very good reason to put data files somewhere in 'inst' :-) > this seems to imply that "inst" is not expected to contain only m-file > code but "any files that are directly installed" i.e. files that do > not need to be compiled before installation. it seems to me that this > includes data files! Well, back in the days where I developed the initial package manager, I just copied the system used for creating R packages. The R-people choose the name 'inst'. I was only thinking of using 'inst' for m-files, so the text in the manual (I think I wrote that) kinda surprises me. Anyway, I'm not against putting data files somewhere in 'inst'. > so my question is: > do we really need to force developers to have a separate directory for > data? what is wrong with the currently documented approach of having > all m-files and data files put into "inst"? > BTW if a particular developer likes to have his/her code/data > subdivided into subdirectories (I usaually do) this is already > possible with the current setup... In the end I think the package maintainer can do whatever he or she likes. Personally, I would recommend putting data files in a 'data' directory, as it seems like less of a mess, but that might be a matter of style. Søren ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
