Comments (10)
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...
from recipes.
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 nameLasagneRecipes
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 installingrecipes
(that project name isn't taken yet on PyPI)
from recipes.
Seems a bit arrogant maybe to hijack 'recipes' for this? I don't know :) It would be the most convenient option I suppose.
from recipes.
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?
from recipes.
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 :)
from recipes.
Yeah I don't suppose this is really PyPI material. Especially because it's largely untested and undocumented.
from recipes.
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?
from recipes.
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.
from recipes.
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.
from recipes.
How about keeping
examples
,papers
andtutorials
as top level directories, and makingdeepfrozen
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).
from recipes.
Related Issues (20)
- 3D UNet implementation HOT 7
- reason behind low value of parameters in VGG19 HOT 1
- error when set values for vgg-19 HOT 2
- modelzoo resnet50.py incompatible to Python 3 HOT 3
- Implementation of Convolutional Spatial Transformer and Siamese network HOT 3
- no sandbox.cuda
- Bad argument to Theano: No. of dimensions changes in the error after reshaping
- Question not an Issue: fliping the arrays HOT 1
- cifar100 with resnet HOT 1
- pretrained network for small images HOT 1
- https://s3.amazonaws.com/lasagne/recipes/pretrained/imagenet/vgg16.pkl HOT 6
- vgg16.pkl without aws cli
- Need help with S3 Browser based downloads HOT 1
- Dice coeff is not changing since the first epoch and binary accuracy changes and is increased to 1?
- Problem with op.grad in OpFromGraph - Guided Backpropagation
- Wrong order of stride and pad arguments in build_simple_block HOT 3
- Broken links in Video features with C3D.ipynb example HOT 5
- Training C3D
- Wrong pretrained weights for UNet example HOT 1
- DICE coefficient loss function HOT 23
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from recipes.