Let's say I create a Rails project and create a default.nix for a nix-shell that will create the development environment for that project via nix-shell .. Naturally, this shell would have whatever dependencies I would need for Ruby on Rails.
Now let's say I also create an AngularJS project and also do the same for that, creating a default.nix to be run via nix-shell ..
Consider, in the future, I may have a project which uses both Angular and Ruby on Rails (hypothetically speaking). Is there a way to take my Angular project's default.nix and my Rails project's default.nix and compose them together without resorting to copy-paste?
Further, let's presume that this project may later require other dependencies. Could I maybe do something along the lines of saving the Rails default.nix as rails-env.nix and the Angular default.nix as angular-env.nix, and then include them in a new default.nix for my Rails-Angular + Extras project so that I can have both the dependencies declared in the rails-env.nix and the angular-env.nix, but also declare additional dependencies beyond those includes, thus maximizing the reusability of my Nix expressions for creating development environments?
A Nix file is just an expression which you can import with import ./path/to/other.nix. You can factor out any expression you like into a separate file and reuse it. It's standard practice to make it a function so you can parametrize it differently for different projects or builds.
Here are some good examples with imports:
http://sandervanderburg.blogspot.ro/2014/07/managing-private-nix-packages-outside.html
And an intro to the Nix expression language, which is rather simple:
https://medium.com/#MrJamesFisher/nix-by-example-a0063a1a4c55
Related
It's a .jar available in various versions at Maven Repo.
But what category is it? It is published by org.codehaus.groovy, the same outfit that I get my groovy-all dependency from. I also find that import groovy.sql doesn't work in a script unless I specifically include this dependency. So it would appear not to be part of the core language.
Outside a Gradle context I find that I have to manually put the .jar file under ~/.groovy/lib in order to use it. If I put the wrong version (e.g. 2.5.9 for 3.0.2) under ~/.groovy/lib the script won't run... even if I'm not using groovy.sql at all!
Is this a "dependency"? It seems a typically powerful and hassle-free Groovy way of manipulating databases. Are there any other powerful add-on (non-core) Groovy .jar file modules like this, which have to be manually placed under ~/.groovy/lib, that I should know about?
groovy consists of subprojects:
https://github.com/apache/groovy/tree/master/subprojects
and groovy-sql one of the subprojects
all subprojects are published in maven as separate libraries
prior to version 2.5 there was groovy-all-XX.jar that includes all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.4.19/
however starting from v 2.5 groovy-all represented by groovy-all-XX.pom that depends on all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.0/
so, to include all groovy features you have to specify groovy-all in your maven/gradle/... dependency
and finally useful site to dig dependencies:
https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-all/3.0.2
lodash supports custom builds with only a subset of the functionality / size. Creating a custom build is a breeze with lodash-cli.
What's the recommended way to take this custom build and integrate it into the project? (using npm / browserify).
Do I create a custom build command that creates the custom build and places it somewhere? (where?)
Is there a canonical way to specify the dependency and integrate into the project?
There are several approaches you can take to use a subset of lodash:
Use the CLI to generate a custom build (a file within your projects codebase) of the features you need
Use npm modules or the lodash modules within your code base (i.e. instead of doing _ = require('lodash'); _.each(...) you would do each = require('lodash/collections/each'))
Use the lodash-modularize tool to create and maintain a custom lodash build for a given project and use lodash as otherwise documented. This is essentially automating the two/three methods above.
Each approach is 100% valid and has their pros and cons
Disclaimer, I'm the author of lodash-modularize
I am new to browserify and its usage is not completely clear to me although the benefits seem to be compelling.
I have a couple of questions and was hoping someone could clarify.
I've seen blog posts about using browserify-shim in the package.json to include third party libraries like jquery and bootstrap. I've also seen posts where tools like gulp are used generate the bundle file. I can't seem to find a good answer on why browserify-shim is required if tools like gulp are able to automate the process. Can someone please shed some light? Why is browserify-shim even required? I feel the gulp solution is a little cleaner although a little more involved. It won't pollute package.json with browserify specific stuff that is a build thing and therefore goes together with gulp (just my personal opinion)
How does one deal with third party libraries that are not in npm and also not public? For example, we purchase a script from a third party. That script is not any common js, but is a regular js file with some dependencies (example, on jquery and underscore).
Browserify lets you take the world of Node and bundle it up for delivery to a browser. It understands Node modules, which define dependencies via CommonJS require statements.
But what if you have some JS code or library that is not defined as a Node module and does not support CommonJS? Enter browserify-shim. It provides a shim wrapper around any script, like your private third party script, so that it can be defined as and used as a Node module that Browserify understands.
The use of browserify-shim is completely orthogonal to how you execute Browserify. There are basically two options there: A) Use Browserify's command line API or B) Use Browserify's JS API.
Using a build tool, like Gulp, implies the second option, since you'd use Browserify's JS API in your Gulp build script (i.e. gulpfile.js). A lot of people prefer the use of Gulp because it has a good ecosystem of plugins that allow you to do a lot more than just call Browserify (e.g. compile CoffeeScript, compile SASS, run JSHint, etc).
So, to answer your specific questions:
Browserify-shim is only required if you have JS code that is not written as a Node/CommonJS module that you need to bundle via Browserify. To do so, you will need to tell browserify-shim which files to shim as modules (and what dependencies they have) in package.json. Note that this is totally unrelated to Gulp; so you will need it whether you use Gulp or not.
What you describe is the perfect use-case of browserify-shim. Put your third party script(s) in your project, configure the files to be modules in package.json per b-shim's documentation, require them in your code, and execute Browserify to bundle them up with your code. You could also bundle them up separately, put them in their own project, etc - however you want to structure it.
A couple things to note:
You can shim just about any JS library this way.
Shimming a JS library to be a Node module changes global scope to be private scope. Hopefully everything in the library is namespaced so that all of its functionality can be exported as a single module, but if it's not, you might have to modify the shimmed code to explicitly attach things to window (which is easy but not recommended) or split the code up into separate files/modules.
Both Browserify and Gulp use streams in their JS API, but Browserify uses native Node streams while Gulp uses Vinyl streams. Since they don't play well together, you'll probably have to use vinyl-source-stream to adapt Gulp to Browserify (e.g. for renaming files in a Browserify pipeline), or use vinyl-transform to adapt Browserify to Gulp (e.g. wrap a Browserify stream for use in a Gulp pipeline).
Here is my situation. I have a play app which uses the guice module. In order to work with the guice module:
I installed it using play install guice. This installs it in the $PLAY_HOME/modules which is fine by me. I don't want to edit the module files in any way whatsoever.
Then I declared the module in my dependencies.yml like so: - play -> guice 1.2
Within my app, I ran play dependencies, and this resoles the module just fine and creates a modules/guice-1.2 file that references the guice module.
The issue is that the content of that file is something like the following: /some-absolute-path/play-1.2.x/modules/guice-1.2.
That works fine when working locally for development. But when I want to move to a production server, with a different install of Play! (i.e. with a different absolute path to it) it will obviously fail.
So what's the best way to deal with this?
For now I've resorted to declaring the module in the application.conf file like this: module.guice=${play.path}/modules/guice-1.2.
Unfortunately the ${play.path} magic doesn't seem to work on those generated files.
By the way I use version 1.2.3 of Play!
you should try with ${application.path} in your dependencies.yml file, like in this example
require:
- play -> crud
- provided -> DateHelper 1.0
repositories:
- provided:
type: local
artifact: "${application.path}/jar/[module]-[revision].jar"
contains:
- provided -> *
see this question: How can I specify a local jar file as a dependency in Play! Framework 1.x
When you run in production you will either resync the dependencies (via play deps command) with the local installation of Play or in some scenarios you can precompile everything and then there will be no issues with the paths.
That second scenario is the one with Heroku, for example.
It's not answer to your question, but I have faced with same issue.
I don't want to call resync the dependencies on production.
I don't want to ask my team members, install special module.
I don't want to commit file containing absolute path with module location.
The only workaround that I find: do not install module in Play! application, just include jars which use this module manually. play-guice.jar should be included as #opensas suggested, aopalliance and com.google.inject as regular dependencies in dependencies.yml.
The funny thing, that resync dependencies is also deleting .svn files, so back-up its before calling this command.
I am using Rhodes to develop android application.
I have installed HTTpary gem in Rhodes. Now when I am writing the statement "require 'httparty' " at top of the application it gives me error like "No such file to load".
What should I do to solve this problem?
From the documentation, scroll down to the section beginning "Adding Ruby Extension Libraries to Your Rhodes Application". It details 3 ways you can include external libraries into your application, summarized below.
Add ruby extension to an individual application
Add ruby library to an individual application
Add ruby library to the Rhodes framework to be built for all applications
The base Rhodes framework only contains things deemed generic enough to be included - so the built application package size can be kept low. Anything not in the base framework can be included in the application through the aforementioned methods.
This is just a guess since w/ Rhodes environment; but if this were a normal ruby script you would need to have require 'rubygems' first (assuming your used rubygems...).
The Motorola documentation is horrendous; allow me to help if I can. Firstly, examine the constant $LOAD_PATHS from your Ruby code to see the entire list of paths that Rhodes searches. Any .rb file in this path is automatically made available to require.
Then you have to decide whether to add this library to the entire Rhodes framework or just your app; personally I opt for one app at a time, because that way it reduces the chances of incompatibilities, and your apps are still provided all the libraries in rhodes-*version/lib/framework
If you want to add a library to your app, the docs suggest plopping it into the directory app/lib, but keep in mind that only this exact path is searched, so if you don't have a .rb file of the same name as your require statement directly under this path, it won't be detected automatically. I mention this because the common structure is a single file with the library name placed directly in lib, and the actual library contents inside a folder of the same name.
Example: the mime-types library is made up of: lib/mime-types.rb and lib/mime/, which are named differently and can lead to exactly this kind of confusion when including in Ruby.