Make Recipes a package?

[ebenolson]

Make Recipes a package?

[benanne]

I think it would be a good idea. It's mainly useful for modelzoo and utils, but maybe some importable stuff will end up in the other subdirectories too at some point.

Perhaps the namespace should be lasagne.recipes, instead of just recipes? But I'm not sure if that is easily achievable without tinkering with the directory structure...

[dnouri]

Last time I checked, setuptools didn't allow to have top-level and subpackage to be different projects. So you can have two software projects with packages called lasagne.core and lasagne.recipes, but not lasagne and lasagne.recipes.

Names that I can think of that would work:

• lasagne_recipes for both project and package name
• LasagneRecipes for project name, lasagne_recipes for package; probably confusing since we'll no longer be able to rely on case insensitiveness of tools like pip when installing
• recipes (that project name isn't taken yet on PyPI)

[benanne]

Seems a bit arrogant maybe to hijack 'recipes' for this? I don't know :) It would be the most convenient option I suppose.

[ebenolson]

parmesan is available on PyPi, we could take that for the 'toppings' package (models, utils, whatever else), and keep the examples and paper replications in Recipes?

[f0k]

Do we need it on PyPI at all? I guess the intended usage is to clone the github repository, and then just optionally install it from there to make it easier to use some parts for temporary experimentation? Or do we actually plan to turn it into a package that people can put in their requirements.txt and such? (If we don't put it on PyPI, we don't need to figure out a name.)

parmesan is available on PyPi, we could take that

If @ebattenberg doesn't plan to publish his own add-ons :)

[benanne]

Yeah I don't suppose this is really PyPI material. Especially because it's largely untested and undocumented.

[f0k]

Also because it's supposed to grow continuously, and we probably don't want to make releases every now and then for no particular reason. People can either use parts of it by copy/paste (I guess that'd be the most common use case), or they can put a git commit in their requirements.txt if they really want to. We don't need to put it on PyPI for that.

So... yes, let's turn it into a package, but not register on PyPI, so just call it recipes. The directory organization still needs some thought, though. I like how you can browse the Recipes on github right now, without any obscure recipes directory in between. That's perfect for the notebooks, and also for copy/pasting things from examples. Maybe some of the stuff (the ipython notebooks, the examples) should stay top-level directories that are not installed ever, and only things that have potential for reuse (some layer or dataset or utility function definitions as well as the deep-frozen models) should wander into a recipes directory or something? Is recipes still a good directory name for that?

[benanne]

I don't know, it might be confusing if half of the repository content is in the top-level and half of it is in the recipes subdirectory. Also we have to make sure people don't start to think that they need to "install a package" to use everything that's under recipes. We should try to make it clear that you can also just cherry-pick the files / parts of files you need.

[ebenolson]

Also because it's supposed to grow continuously, and we probably don't want to make releases every now and then for no particular reason. People can either use parts of it by copy/paste (I guess that'd be the most common use case), or they can put a git commit in their requirements.txt if they really want to. We don't need to put it on PyPI for that.

I agree with all of this.

I don't know, it might be confusing if half of the repository content is in the top-level and half of it is in the recipes subdirectory. Also we have to make sure people don't start to think that they need to "install a package" to use everything that's under recipes. We should try to make it clear that you can also just cherry-pick the files / parts of files you need.

How about keeping examples, papers and tutorials as top level directories, and making deepfrozen an installable package? utils could be a separate package (with a less generic name).

It would be nice if they could be in the lasagne namespace, but I think that would require adding a namespace package to Lasagne, and putting the content here under lasagne/addons or something like that, which would make it more confusing to the casual observer.

[f0k]

How about keeping examples, papers and tutorials as top level directories, and making deepfrozen an installable package? utils could be a separate package (with a less generic name).

Yes, that's also an option -- having two top-level directories that can be installed, and the others for free exploration. We're polluting the user's namespace a bit then (with both deepfrozen and the-name-for-utils), but what can you do. Otherwise we'd need to hide everything in a recipes directory and to the casual observer it would look like any installable package (with a single directory and a setup.py and some other metafiles).