I am trying to add a new recipe to a project and it seems to work when it's called foobar but not when it is called foo_bar. I can't find anything in the documentation.
Are there any restrictions on what a name can look like?
Related
I wanted writing an IDE plugin to simplify work with references to code in my documentation, but decided to first check the existence of a specification (like URI) so as not to reinvent the wheel.
I tried to find the answer to this on the internet but failed.
We know that such references work in different IDEs:
appRoot.folder.file.Class#method
appRoot.folder.file:35
appRoot/fodler/file.ext:35
But what if you need to get the path to the nested property JSON or XML?
I naively imagine that the sign # means the root and then for the JSON path I could use something like this:
appRoot/folder/jsonFile.json#oneLevelProp.twoLevelProp
But this of course does not work at the current moment in any IDE that I know of.
in yocto imagebuildscripts there is a config variable named "IMAGE_FEATURES" i want to create a custom Imagefeature.
I searched my yocto installation which runs poky for existing imagefeatures but i wasn't able to find it.
IMAGE_FEATURES is a bit special, as its basically being hardcoded into image.bbclass.
Generally you are way better off creating custom DISTRO_FEATURES, and triggering on them whereever needed. See packagegroup-core-boot as an example of a recipe changing behaviour based on DISTRO_FEATURE in various places.
Usage wise there is little difference, the only thing you can't do is set DISTRO_FEATURES in the image recipe. If that is your actual need, then you probably should pour the new functionality in a custom image class the includes and extends image.bbclassm and call it myimage.bbclass (or similar).
EDIT:
Initially, I referred to the dropbear recipe as an example that triggers behaviour based on systemd being set as DISTRO_FEATURE. This is technically correct (and it was the first recipe that came to my mind), but probably confusing as there is a dropbear spedific IMAGE_FEATURE too.
I just started using puppet. I don't know how to execute classes in puppet.
I've my files "config.pp init.pp install.pp service.pp".
For example install.pp :
class sshd::install{ ... }
Next, i declare my class in init.pp with "include sshd::install".
I also tried to run classes with :
class{'sshd::install':} -> class{'sshd::config':} ~> class{'sshd::service':}
After that, i launch "puppet apply init.pp" but nothing.
My scripts work individualy, but with classes i don't know how to execute all my classes.
Thanks
I'm not sure how much research you've done into Puppet and how its code is structured, but these may help:
Module Fundamentals
Digital Ocean's guide.
It appears that you are starting out with a basic module structure (based on your use of init/install/service), which is good, however your execution approach is that of a direct manifest (Not the module itself) which won't work within the module you are testing due to autoloading unless your files are inside a valid module path.
Basically: You want to put your class/module structured code within Puppet's module path (puppet config print modulepath) then you want to use another manifest file (.pp) to include your class.
An example file structure:
/etc/puppetlabs/code/modules/sshd/manifests/init.pp
install.pp
service.pp
/tmp/my_manifest.pp
Your class sshd(){ ... } code goes in the init.pp, and class sshd::install(){ ... } goes in install.pp etc...
Then the 'my_manifest.pp' would look something like this:
include ::sshd
And you would apply with: puppet apply /tmp/my_manifest.pp.
Once this works, you can learn about the various approaches to applying manifests to your nodes (direct, like this, using an ENC, using a site.pp, etc... Feel free to do further reading).
Alternatively, as long as the module is within your modulepath (as mentioned above) you could simply do puppet apply -e 'include ::sshd'
In order to get the code that you have to operate the way you are expecting it to, it would need to look like this:
# Note: This is BAD code, do not reproduce/use
class sshd() {
class{'sshd::install':} ->
class{'sshd::config':} ~>
class{'sshd::service':}
}
include sshd
or something similar, which entirely breaks how the module structure works. (In fact, that code will not work without the module in the correct path and will display some VERY odd behavior if executed directly. Do not write code like that.)
I have a question regarding the file loading system from Cakephp2.3.
I have two plugins - let's call them "Contacts" and "Managers", loaded like this:
CakePlugin::load('Contacts');
CakePlugin::load('Managers');
Each of them has a controller called "DashboardController.php" with an index() action.
When I try to access the dashboard page for "Contacts", sometimes I see the following error:
Error: Class "ManagersAppController" not found
even though the url looks like this:
http://mysite.com/contacts/dashboard
I read that Cakephp2.3 doesn't support namespaces and this might happen because I have two php classes (DashboardController.php) with the same name. At the same time, I know that Cake should map the plugin name first, so it should be able to handle duplicate file names.
Do you have any idea why I'm seeing this random error?
Thanks for your help.
I just found the answer from the guys the developed CakePHP. Indeed, you can't have two controllers or models with the same name, even though they are located in different plugins.
This happens only in CakePHP2.x and I quote:
This is a known limitation of Cake2.x and the lazy loading approach
using App::uses()
You can see my question and their answer here: http://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/3558-loading-file-from-a-different-plugin
The solution is to rename the controllers/models with conflicting names and/or name all controllers and models from a plugin using the plugin name (ex. DashboardController.php will become ContactsDashboardController.php)
When I use catalyst.pl to auto-generate my application, the AUTHOR section of the POD includes only my name like this.
Kiffin Gish,,,
What are the missing fields and how can I use them? Is it possible to use another boilerplate for the PODs?
It's using the GECOS field from your line in the passwd file (courtesy of getpwuid). You can change the author name that shows up by setting the AUTHOR environment variable, although this doesn't seem documented. As for overriding the entire thing: not so much, unless you want to write your own catalyst.pl that uses a custom subclass of Catalyst::Helper, or submit the patch to -Runtime to let everyone do that.:)