requirements.txt

[jvrmaia]

I think will be nice use it for contributors build your own environment. =)

http://www.pip-installer.org/en/latest/requirements.html

[danilobellini]

To install and to use some basics, AudioLazy has no requirement at all. You need PyAudio to play some song and you'll obviously need MatPlotLib if you need plots, but these aren't requirements for the package. The user should be able to install and use the package without any other package installed.

There's a description in the README.rst talking about that, including examples and testing requirements. If that's not enough, please let me know. I really didn't put the optional packages in the "extras"

http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies

[jvrmaia]

Installation guide, ok! requirements.txt is more useful for people who wants fork and make pull requests.

Other thing, for each example will be nice something like too.

[danilobellini]

Although surprising, ok, that's not about installation.

If you try testing, it'll xfail (xfail means "expected to fail") when a test needs something that isn't available, with a reason message "Module name_module not found" (which can be seen calling py.test -rsx from inside the package directory, i.e., from where pytest.ini lies). You shouldn't need a full environment even for testing (besides the pytest, pytest-cov and pytest-timeout, as I said in the README.rst).

For now, there's one doctest that would fail if you don't have numpy, but you still can run the entire test suite. That's because pytest doesn't allow skipping/xfailing inside docstrings up to now (I already made a pull request there to allow such). That docstring (line, in lazy_synth.py) is something I think that shouldn't change in AudioLazy.

What I think you're missing is perhaps a tox.ini or something like a developing.rst guide with a getting started section to help developing into AudioLazy, with contents like what I'm saying here. Mostly of AudioLazy was done as an "external" script using AudioLazy before adding it to the package (the scripts already included the tests). Changing such a script to insert the feature into the package afterwards is really simple: usually the biggest change is to use relative imports instead of a from audiolazy import *. That's how I created the x object, each part of the entire lazy_auditory.py, lazy_analysis.py, etc.. You can add strategies to StrategyDict instances, you can monkeypatch a class in which you want to see a new feature, etc.. Unless you're changing a metaclass, the meta function, or doing something that changes the AudioLazy interface breaking existing tests, I think that's the easiest way to add a feature in AudioLazy.

With the examples you mean changing the docstring of each file to include its requirements? Each example have exactly one script file (they don't have a setup.py). I don't think a verbose example would be any help, but I can surely make better docstrings if needed.

Creating an empty requirements.txt really makes no sense for me, and I think the project shouldn't have any "strong" dependencies (anything that avoids installation, updating or using the package basics), all you need is Python 2.7, 3.2 or 3.3. AudioLazy also shouldn't "block" you from updating/removing NumPy, MatPlotLib, etc.. Perhaps I'm missing some use case for that file, if that's so please let me know.

[danilobellini]

I think that the tox.ini "deps" values as well as the tox automation and Travis/Coveralls CI deprecates this issue, which was about requirements for testing environments.

Also, I don't like the idea of dividing the project metadata into "thousands" of files unless needed. Today all py.test, tox and coverage/pytest-cov configuration are done by one single file: tox.ini. Even for installation dependencies, a requirements.txt file wouldn't be needed, since that would be done by a simple "install_requires" keyword argument of setuptools.setup (in setup.py).

Seeing tox.ini or typing tox --showconfig one can see [in the deps and commands keys] how the testing environments are configured.