My config files structure:
config
├── train_dataset
│ ├── adobe5k.yaml
│ ├── my_train_data1.yaml
│ └── cifar10.yaml
├── valid_dataset
│ ├── adobe5k.yaml
│ └── cifar10.yaml
└── config.yaml
And my config.yaml is:
# other configs
...
defaults:
- train_dataset: adobe5k
- valid_dataset: adobe5k
As you see, I have 2 fields named valid_dataset and train_dataset in my config, whose value is selected from its own config group. What should I do to make values of the two fields selected from the same group?
You can use a config group more than once. Assume that you moved your dataset configurations into a single datasets directory. Then you can re-use them as follows.
- defaults:
- datasets#train_dataset: adobe5k
- datasets#valid_dataset: adobe5k
You can use Defaults List interpolation to achieve that. The Default List page high level information and you find a more practical example here for some details.
defaults:
- train_dataset: adobe5k
- valid_dataset: ${train_dataset}
This way, it will be enough for you to override train_dataset and the validation dataset would match it automatically (unless you override it too).
Related
I have a project with a proto files in a:
$ tree proto/
proto/
├── common
│ └── request.proto
├── file
│ ├── file.proto
│ └── file_service.proto
├── job
│ ├── job.proto
│ └── job_service.proto
├── pool
│ ├── pool.proto
│ └── pool_service.proto
└── worker
├── worker.proto
└── worker_service.proto
5 directories, 9 files
I want to generate a one single file from worker_service.proto but these file has imports from common.
Is there a option in grpc_tools.protoc to generate one single python file?
Or is there a tool to generate one proto file?
Based on the information, I guess by generate one Python file means: instead of generate one Python file for messages (*_pb2.py) and one Python file for services (*_pb2_grpc.py), you hope to concatenate both of them into one Python file. To take a look at the generated file content, here is the Helloworld example.
Combining the two output file is currently not supported by the gRPC Python ProtoBuf plugin (unlike Java/Go). You can post a feature request and add more detail about your use case: https://github.com/grpc/grpc/issues
Let's assume a config group foo and config files organized in the following directory structure:
conf
├── foo
│ ├── bar
│ │ ├── a.yaml
│ │ ├── b.yaml
│ │ ├── c.yaml
│ └── baz
│ ├── d.yaml
│ ├── e.yaml
│ └── f.yaml
Each of the yaml files sets the package to foo using # #package foo. When running the corresponding application, I can simply override foo by specifying something like foo=bar/a or foo=baz/f. Thereby, the sub-directories bar and baz indicate a certain category withing a larger set of possible configurations.
While this works fine for standard use in hydra, some more advanced features of hydra appear to be not compatible with this structure. For instance, I would like to use glob in conjunction with the directory structure like this foo=glob(bar/*) to sweep over all configs of a certain category. However, this does not appear to work as glob does not find any configs in this example. Also if I assign an invalid config to foo and hydra lists the available options, the list is empty.
This makes me wonder if structuring within a config group is a generally supported feature in hydra, and just some corner cases are not covered yet, or if I am using hydra wrong and directories should not be used for organizing configs in a group?
This is not recommended, but not explicitly prohibited.
There are scenarios where this can help, but as you have discovered it does not play well with some other features. A config group contains other config groups/configs.
Hydra 1.1 is adding support for recursive default lists which will make this kind of scenario more common.
See The Defaults List documentation page:
├── server
│ ├── db
│ │ ├── mysql.yaml
│ │ └── sqlite.yaml
│ └── apache.yaml
└── config.yaml
In the scenario from the example there, the entities under server/db are different than the entities under server, so such globing would not make sense.
I understand how and why to structure a Symfony project. I just wonder if is there any preferred structure under the /src direcotry. Beside the Controller, DependencyInjection, Entity etc. how do you organize your source code?
Just crowd everything under Model? Group larger logical bulks into dirs like Service, Model, Job etc? Some group their files by functionality like:
Order, Product, PopupManager etc. What is the most useful?
There are many answers to this question. I think it highly depends on what your application involves. The following are some suggestion but keep in mind that you need to imagine the structure of your application by yourself.
Little project (less than 6months and a not too much of maintenance):
.
├── Controller
├── Entity
├── Factory
├── Provider
├── Repository
├── Security
└── YourCustomThing
Or if you prefer a domain approach (I do) you can have more something like this:
.
├── Product
│ ├── DTO
│ └── Model
└── User
├── Model
├── Provider
└── Security
If you have a more complex application, then you should probably learn about DDD or CQRS. Here is a little DDD example inspired by the DDD Cargo Sample (but there is a lot more to tell about DDD apps, as well as CQRS ones).
.
├── Application
│ ├── Booking
│ │ └── Dto
│ └── Exception
├── Http
│ └── Action
├── Infrastructure
│ ├── Persistence
│ └── Product
│ ├── ActionFactory
│ └── BookingFactory
└── Model
└── Shop
Hope it helps.
I am using Sprockets with Sinatra, as suggested in Sinatra's page docs, but I can't make it work.
When I go to localhost:4567, the page loads correctly but with no styles. If I go to localhost:4567/assets/app.css, I get a not found error. I wonder what I am missing or what is wrong in the way I am using Sprockets?
This is my folder structure:
├── assets
│ ├── css
│ │ ├── app.css
│ │ ├── base.css
│ │ └── normalize.css
├── bin
│ └── app
├── lib
│ ├── app_assets.rb
│ └── main.rb
├── spec
│ ├── spec_helper.rb
│ └── main_spec.rb
├── views
│ └── index.erb
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── .rspec
└── .ruby-version
The contents of app.css are:
//= require normalize
//= require base
The contents of app_assets.rb are:
module AppAssets
def self.environment root_path
environment = Sprockets::Environment.new root_path
environment.append_path './assets/css/'
environment
# get assets
get '/assets/*' do
env['PATH_INFO'].sub!('/assets', '')
settings.environment.call(env)
end
end
end
The contents of lib/main.rb are:
require 'sinatra'
require 'sprockets'
require 'app_assets'
class Main < Sinatra::Base
set :views, "#{settings.root}/../views"
get '/' do
erb :index
end
end
The file views/index.erb contains the line:
<link rel="stylesheet" href="assets/app.css">
And the contents of bin/app are:
#!/usr/bin/env ruby
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '..', 'lib')
require 'sinatra'
require 'sprockets'
require 'app_assets'
require 'main'
Main.run!
Which I run typing:
$ bin/app
Any help would be appreciated, I'm sure I made something wrong but I can't see what. Can anybody spot it?
The app_assets.rb file is the problem here. When you require this file inside another file, the methods you define inside this module are not automatically included. You need to explicitly include AppAssets wherever you need the self.environment method to exist.
The second issue here is that self.environment is not equivalent to settings.environment. If I understand correctly, what you're trying to do is define the asset routing whenever the module gets included. To achieve this one way is to use the included hook for modules. This hook gets run every time you include a module inside a context. If you use that, the code in app_assets.rb turns to:
module AppAssets
def self.included(klass)
environment = Sprockets::Environment.new klass.settings.root
# note the change to path. Since the file where this gets included
# is inside a sub-folder, we need to traverse to one level above.
environment.append_path '../assets/css/'
klass.set :environment, environment
klass.get '/assets/*' do
env['PATH_INFO'].sub!('/assets', '')
klass.settings.environment.call(env)
end
end
end
The klass argument to this hook is the class into which this module is included. In our case this is the Sinatra class you've described in main.rb. That file looks like:
class Main < Sinatra::Base
include AppAssets
# Same as what you have
end
There's a Sinatra Recipes article about using Sprockets with Sinatra: http://recipes.sinatrarb.com/p/asset_management/sprockets?#article
In my symfony 2 project I have a bundle at
src/Cinergy/Bundle/PeopleServiceBundle
Now I'd like to generate a CRUD controller based on a doctrine entity, but I'm constantly failing to enter the correct string for the entity parameter.
I tried things like:
php app/console generate:doctrine:crud --entity=Cinergy/Bundle/PeopleServiceBundle:Group
or
php app/console generate:doctrine:crud --entity=#PeopleServiceBundle:Group
All of them return erros like:
[Doctrine\ORM\ORMException]
Unknown Entity namespace alias '#PeopleServiceBundle'.
What's the right syntax for the --entity parameter? Or is there something missing after all?
This is how the directory structure looks right now:
src/Cinergy/Bundle/PeopleServiceBundle/
├── Controller
│ ├── GroupController.php
│ └── PersonController.php
├── DependencyInjection
│ ├── Configuration.php
│ └── PeopleServiceExtension.php
├── PeopleServiceBundle.php
├── Resources
│ ├── config
│ │ ├── routing.yml
│ │ └── services.yml
│ ├── doc
│ │ └── index.rst
│ ├── public
│ │ ├── css
│ │ ├── images
│ │ └── js
│ ├── translations
│ │ └── messages.fr.xliff
│ └── views
│ └── Default
│ └── index.html.twig
└── Tests
└── Controller
├── GroupControllerTest.php
└── PersonControllerTest.php
After all it turned out that I have to create the entity before I can create the CRUD controller for it. Of course that makes sense. Unfortunately the Sensio Generator Bundle documentation does list the operations in the oposite order which pushed me into the wrong direction.
This means the correct order ist
Generating a New Bundle Skeleton
Generating a New Doctrine Entity Stub
Generating a CRUD Controller Based on a Doctrine Entity
First you need to register your bundle into your AppKernel.
Then simply run the following command.
Don't put # before the bundle's name
php app/console generate:doctrine:crud --entity=PeopleServiceBundle:Group
More about generating a CRUD controller based on a Doctrine entity.
According to the symfony docs, you have to use " The entity name given as a shortcut notation containing the bundle name in which the entity is located and the name of tvhe entity", so it should be something like
--entity=CinergyPeopleServiceBundle:Group
If you have more than one Bundle and want to use different database connection just update your config.yml and parameters.yml by adding configuration and parameters.
This will solve problem with CRUD generation.
I searched for hours until I found out that in my app/config/config.yml under doctrine.orm I removed auto_mapping: true which caused the issue. This may be useful for other people :)
If it still relevant for someone :)
guys, it's because DoctrineBundle DoctrineExtension compile the list of valid aliases based on all registered bundles, that have 'Entity' (or other configured) folder in them.
So in order to use doctrine:generate:crud or generate:doctrine:crud,
you have to create just folder Entity in your bundle, and not required to create entity first (as command says - it's true).
So you it will work if you already have some entity in your bundle,
or if you have just empty Entity folder in your bundle.