I'm in the process of learning Chef to so I can deploy projects built with Python.
I have my own Cookbook where I am writing my own custom recipes. I've also downloaded the poise-python cookbook. Both sit in the same "cookbooks" path in my app.
What I am trying to figure out is how do I include the methods from poise-python so I can use them in my custom cookbook?
Thanks,
RB
You need to define your dependency in your metadata.rb file for your cookbook. Like this:
depends 'poise-python'
For this particular dependency this is enough to use the custom resources it provides. You should review any dependency's README.md for guidance on using it. You can find poise-python's here. You should also review it's dependencies to be sure you have all of these available (uploaded to your Chef server, or in the cookbooks directory for Chef solo).
Familiarizing yourself with Policyfiles is recommended for dealing with dependencies at a greater scale.
Related
Q. How can the generator-jhipster leverage an internal distribution point, e.g., Nexus NPM, &tc. for jhipster blueprints?
Background
We are adopting JHipster for several major application and service initiatives building on the Java and Angular integration and tooling. We will have changes to some of the standard behaviors and will introduce an internal blueprint and a corporate theme (meeting branding standards).
What is not clear in the documentation is distribution of the blueprint and theme. Our blueprints and theme are not, naturally, suited for distribution on the JHipster marketplace.
A .blueprint folder is an option but not ideal for multiple teams and what may be many projects. npm link is not a shared configuration, requiring each team member, across multiple teams, working in different sprints cadences, &tc., to execute. I've given some consideration to git submodules, and while recently improved in Git, has dev workflow friction—and is esoteric enough—that adoption and maintenance might have to high a threshold at scale (and don't get me wrong, I loved—loved—the "vendor branch pattern" seen in SVN, coupled to SVN exports.)
Is there a hook into the generator to point to an internal distribution point?
Thanks!
I think I answered my own question reviewing other blueprints.
The JHipster Marketplace is optional and promotes blueprints for wide use. A blueprint may or may not desire this visibility.
Blueprints are NPM packages
As an NPM package, the "namespace" consists of the prefix generator-jhipster-, e.g., generator-jhipster-myblueprint and is resolved from a registry.
Given #3, if your organization has an NPM registry, e.g., Nexus, Artifactory, other, generator-jhipster --blueprint myblueprint resolves normally.
Feedback is appreciated.
In Installing SAP Commerce Using Installer Recipes and Installer Recipe Reference, there is a comment that says something like:
The installer is currently only intended to install SAP Commerce in
development environments or for demonstration purposes. Do not use the
installer to install SAP Commerce in a production environment.
However, guides like Customizing the Accelerator with extgen and modulegen usually mention recipes:
On Windows: install.bat -r b2c_acc_plus
So, how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
I don't see clear instructions (or best practice) on how I should build a B2C/B2B application from scratch for development and then preparing it for Production. (Maybe there is a gap in the instructions, or I just don't know where it is)
Even the Installing SAP Commerce Cloud for use with Spartacus guide mentions starting with a B2C recipe. Does this mean that the starting point of building a SAP Commerce project is to use recipes? Are there cases where you would not use a recipe, and build everything from scratch using ant modulegen and ant addoninstall?
It is not recommended to use recipe for direct installation on production. Reason being it installs a preset of hybris extensions which might or might not be needed for your requirements, also it might not be a allowed to use under the license you got.
However, when you start your development, you can use recipe to give your development a quick start. It generates the raw structure for your e-commerce application which you would need to customize and later deploy on your production.
how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
Well, You can use any of those. If you are looking for difference, it has already been answered here
how I should build a B2C/B2B application from scratch and prepare for production?
For production hybris deployment procedure refer this.
NOTE :
a) recipe installation does more than what you can achieve using modulegen like complete installation, configuration and initialization for a running e-commerce example. I think once you go through above links, you will have a much better understanding on this.
b) When you go with recipe, it will install related extensions which you might not want to use or don't have production license for that. Please be considerate to review and disable such extensions,
Thanks
A few more points adding to the answer by www.hybriscx.com
Generally, the integrations in a recipe are mock integration e.g. payment integration as the purpose of a recipe is to provide a ready-to-use demo/reference application (store).
The data (catalog, users & password, usergroups, roles, promotions etc.) in a recipe are sample data. The same goes with the look-n-feel (logos, colour, layout etc.). Every business requires its specific data and look-n-feel.
The system configurations/properties (e.g. memory configuration, logging configuration etc.) may be optimised for the demo purpose but the production setup may require a different configuration. On the same line, configurations like hosts, ports, encryption etc. are general purpose configurations and a production environment may need to change them.
The database set up by a recipe is generally HSQLDB which is only good for development/demo.
How can I share components across multiple react projects without having to publish them on a public package manager like NPM?
Option 1: You can use npm and use private packages so they're not external facing. There are also artifactories and scoped packages that usually represent company-wide projects that can be public or private. See https://docs.npmjs.com/private-modules/intro and https://docs.npmjs.com/misc/scope.
Option 2: Essentially, you can develop projects with a flattened structure. You can then import various projects and/or components into other projects or folders. This is entirely dependent on your codebase and configuration. With this model though, a lot of times publishing to npm comes fairly naturally since each folder may be its own project with its own package.json.
Updated:
Option 3: Bit focuses on the composability of components from everything from the little things like a button to the actual view and app itself—each target is its own package. Overall, it's an opinionated, yet customizable framework that can enable quicker development, managed dependencies, and organized code.
Option 4: RushJS is a monorepo manager built by Microsoft that allows for flexibility of different kinds of apps and services utilizing pnpm underneath (as opposed to yarn and npm), which alleviates problems that stem from dependency issues.
Check out Bit:
Bit is an open-source cli tool for collaborating on isolated components across projects and repositories. Use Bit to distribute discrete components from a design library or a project into a standalone reusable package and utilize it across applications.
You could also upload them to a private git repo such a Github and then pull them in from there.
Ryanve has a nice example over here: https://stackoverflow.com/a/28729646/1592783
You could create a repo of shared components and then have your Node.js start script call a shell script to do a git pull from that repo and the move the shared components from that directory to your project's directory. That way, every time you call run 'npm start' you will have the latest version of the shared components loaded into your project
In order to present a brand new way of developing a web application, our team decided to create an Angular 2 web application that will be integrated within an already existing Maven Project in Eclipse Mars which DOES NOT use NodeJS nor Angular.
We are currently using the frontend-maven-plugin belonging to com.github.eirslet and managed to download and install both node.exe and npm.
Now, here is the deal: our web application has its own package.json file with all the configuration required to run properly, BUT we would like to be able to differentiate between the web applications, as each one of them belongs to a different working directory (i.e. com.webapp.app01, com.webapp.app02, ...).
As the plugin does not let the user use the npm install command on different directories, we were wondering about how we could reach this goal... maybe using a general package.json, but generating all .js and dependency files in each project directories.
Would that be something even possible?
Could you give us some help?
Thank you.
Cheers!
What I would suggest is to have a multi-module maven project, with a common parent, and children, that would give you this kind of architecture:
parent-project
|-child-project1 (java project)
|-child-project2 (webapp1)
|-child-project3 (webapp2)
|....
|-child-projectn (webapp n-1)
This way you can have for each web-app the frontend plugin available. And you can handle the flow of the build from the parent project (for instance if webapp2 needs to be built before webapp1, you can orchestrate it from the parent)
We decided to generate all the libraries locally and upload them to SVN, due to the fact that the already existing structure cannot be changed and the maven plugin is too much limited for our purpose.
Thank you for your replies, though. :-)
At our company we have at the moment 5 web applications that are built using Gulp. For Gulp, we have a common buildfile that all applications use (and override certain parts of it if needed).
This makes it very easy to add features or fix bugs in all projects at the same time. However, I still need to edit the package.json file in each project separatly if I want to add a new npm dependency or bump a version for an existing one.
What I would like to accomplish is to a "base file" where all the common dependencies are configured, and the I would like to import that into the "local" package.json in each project. It would also be nice if each project could add more dependencies than the ones registered as common.
Is it possible to do this?
No, and it's a good thing that it isn't. You need to declare your dependencies explicitly on each project.
What you can do, if your build process is a shared API, is to extract your build script into an npm package of its own, and include that in the package.json of all other projects, and use it in them (coding it in a way that allows for overrides)
Then when you need a new dependency for your common build, you only need to change it once. (Note that with this, you'd still need to make sure your build package version is up to date in all other applications)