Reorganise repository to more closely match Julia layout .....

[sanguineturtle]

This PR reorganises this repository to harmonise it with the Julia repository.

1. Updates quantecon/ to src/. [Note: This goes against some python style guides, but is useful in this instance to more closely match the repository structures between python and julia]

@spencerlyon2 Given our test data files are currently pretty small - do you see a reason not to distribute them as part of the quantecon python package?

@jstac This currently implements option 2, packaging the test data for distribution. Therefore when nostests runs it will technically import from the system installation and not the local package. Due to this fact, it may be more robust if we wrote a Makefile for make test which would install the latest and then run nosetests.

Feeback / Comments most welcome.

[coveralls]

Coverage remained the same when pulling b47d30c on reorg into 2eb7404 on master.

[albop]

@sanguineturtle I strongly advise against refactoring python directories to match julia ones. The nice thing with python packages is that they are all structured in the same way so that you know what to expect. To me, it would need a stronger case to go against Python conventions, especially given that Julia conventions are not yet set in stone (src directory will probably stay but the subdirectory structures and modules may not). By contrast, having an importable quantecon directory in the distribution is quite useful, especially when dealing with Python packaging system.

In general, we should avoid as much as possible to version binary files. Are the test files small enough so that they could be downloaded as part of the test process ?

[davidrpugh]

@sanguineturtle

I completely agree with @albop. We should following the social conventions for Python directory structure and not try to make it consistent with Julia's.

[sglyon]

I also agree with @albop and @davidrpugh .

I think the goal of the Python and Julia libraries are to be top-notch libraries for doing quantitative economics in Python and Julia. As such, I think that both packages should adhere to standards people expect from top notch packages in each language.

@sanguineturtle, @albop: I don't really feel strongly about the test data. It would be easy to have them available online and attempt to download them when our tests run as @albop suggested. But, they are static enough that I don't think it would be bad to distribute them as part of the package. I'll happily support whichever decision is made.

[jstac]

@albop @davidrpugh @spencerlyon2

This was my suggestion. One of the easiest ways to draw new developers in is to ask them to help keep the two libraries in sync, and it's easier for them if the directory structures are the same. Second, it's much easier to pluck code out of the right places for the lectures programmatically if the libraries have the same structure.

Nevertheless I'm going to back down in the face of unanimous opposition (and fair comments). @sanguineturtle My apologies for wasting your time. Please delete this branch.

[sanguineturtle]

@jstac Ok - I will close issue and delete the branch.

@spencerlyon2 @jstac @albop Our data files are 1kb and 44.1kb. While I agree with the general principle of following an astropy style of download process for test data. Given the current small size, and relatively static nature of the test data; I propose we add them to the package for distribution (if we are distributing the tests then we should probably distribute the data). I will then open an issue to document future release improvements (including a test data download feature etc.)

[jstac]

@sanguineturtle Thanks. Regarding test data, I'll stay out of it unless there's a problem.