I am trying to build an app that is based on riak_core, the problem is that the dependency graph seems to have conflicts.
https://github.com/zkessin/riak_sets/blob/master/rebar.config
The problem seems to be that riak_core includes exometer_core, which includes folsom, and the tag and required version do not match. Is there a way to tell rebar to ignore that?
Found out you can use rebar with --force to fix this, rebar 3 will also fix this without that
Related
What's the ros way of linting ros code?
For ros1 I have found roslint but it is unclear to me if this is the recommended way to lint ros code and if it is still maintained/supported (last commit from three years ago).
For ros2 I couldn't find any official lint solution.
Not sure if there is "the ROS way of linting". For your Python/C++ code you can basically use any standard Python/C++ linter.
In addition (when using ROS 1) I can highly recommend catkin_lint, which checks the package definition and notifies about issues like inconsistent dependency declarations or missing install commands (especially the later can save a lot of time when moving from a devel workspace to installing packages on the robot).
The ROS2 development guide explains the rules used. Link1 and Link2
There is a linter located in ament_lint to enforce some rules.
To run the linter automatically as part of the tests of the package (use BUILD_TEST):
depend on ament_lint_auto and ament_lint_common:
Src file example Package.xml
<test_depend>ament_lint_auto</test_depend>
<test_depend>ament_lint_common</test_depend>
2 lines to your CMakeLists: (with BUILD_TEST)
Src file example CMakeList
find_package(ament_lint_auto REQUIRED)
ament_lint_auto_find_test_dependencies()
I am trying to use eflame to profile CouchDB code to investigate some performance issues in my application. I tried adding the eflame dependency in rebar.config.script (https://github.com/apache/couchdb/blob/master/rebar.config.script)
However I get an error when I run configure to build CouchDB (2.0.0) from its source:
Dependency not available: eflame-.* ({git,
"git://github.com/proger/eflame.git",
{branch,"master"}})
ERROR: compile failed while processing /tmp/couchdb: rebar_abort
Makefile:67: recipe for target 'couch' failed
My change in the rebar.config.script in CouchDB source was adding a single line below (with a comma in the previous line of course)
{eflame, {url, "git://github.com/proger/eflame.git"}, {branch ,"master"}}
I tried various combinations of specifying the dependency as shown in rebar documentation but without any success.(I took into account the order of arguments in the MakeDep function in the rebar.config.script and accordingly tried to pass the arguments)
Any pointers to resolve will be greatly appreciated. Thanks! (Note : I am not familiar with Erlang or rebar , so please excuse any obvious mistakes)
It looks like what's missing in your case is the second argument of the tuple, that requires the version number. You can use an asterix there if you don't need a specific one:
{eflame, ".*", {git, "git://github.com/proger/eflame.git", {branch, "master"}}}
Alternatively, if you are using rebar3, you could use the hex package:
{eflame, "1.0.1"}
There were two issues here
1)The version of rebar I was using was not > 1.5
2)I had to add get-deps before doing a rebar compile as given in this rebar dependencies issue post
I create a yeoman generator to help myself with front end development.
The problem is, our development environment, framework, plugins are changing so fast...
I have to update dependencies in the package.json in yeoman generator's template directory.
But, usually the package.json in yeoman generator is renamed like _package.json, because of the generator, so I cannot do just npm update.
So, I'll ask you what is the best way to update node modules in _package.json.
Thanks.
For what it's worth, npm update just update dependencies to the latest version matching your package.json dependencies semver ranger. It won't update the file itself.
To know which dependencies are outdated, you can either use npm outdated or a tool like david.
What I usually do with my project is to run one of these tools on a newly generated project. This might not seems ideal, but it's actually the best way to go because:
You ensure your generator is still working (things can break overtime if we're not careful)
You'll be able to test the new versions against your project and see where you need to fix your code so it work with latest release and breaking changes.
Also, npm using semver to set versions, this mean you only need to bump dependencies when a new major version is released. This tends to not happen all that often.
#Simon
Thank you for mention that I misunderstood the behavior of npm update.
Now I do the following step to update _package.json in generator.
create project from the generator yo generator-name
update package.json use npm-check-update.
ensure everything goes ok.
copy package.json into _package.json in generator
But I want to do this like
automatically update package.json in generator
start new project
ensure everything goes ok
I'm not sure this is the best way though...
I've created a tiny project [0] to reproduce an error in a controlled environment. The facts, I'm using jenkins to build my project, a big one, I'd like to make some parallel builds. Let me make it graphically
[MyBasicPackage] -----> [MyPackageTester] ------> [MyBasicApp]
.
.
+-----> [...]
+-----> [...]
this is the organization I've made on [0], I have a class TMyUnit (MyBasicPackage) registered on spring container to be tested. I build it and generate its .dcu, .bpl, and so on.
The second stage I build my MyPackageTester that requires MyBasicPackage. Finally I build the app that requires MyPackageTester. So far so good.
When I try to build my MyBasicPackage on, say PC-00, get the artifacts and try to build the the MyPackageTester on PC-06 (same arch, same OS, same IDE, same spring4d version), and a nice error arise:
Unit TMyUnit was compiled with a different version of Spring.Container.Registration
so, I update my spring4d on both machines (PC-00 and PC-06) and build them. Run... and same error arise.
check the library path options (C:\Program Files (x86)\Embarcadero\Studio\14.0\Componentes\spring4d\Library\DelphiXE6\Win32\Debug), delete dcu files and build them once again on both machines, same error.
copy dcu files from PC-00 to PC-06 to avoid any kind of system configuration and the same error arise.
Probably I'm trying to do something that's not possible so far. I've googled a couple of days without luck.
Any ideas?
Please feel free to fork or pull request the example ;)
Regards
[0] https://github.com/graguirre/DelphiDepencyExample
In your case you need to build with the Spring.Core runtime package. Not only will that prevent this error but your code will actually work.
If you do not then all modules will hold their own version of the GlobalContainer instance you are using and nothing will work.
Maybe one solution is put all your libraries in a centralized repository and pull them to compile your projects. It should resolve the different version error.
I'm attempting to understand how to build a multiple-application Erlang OTP release using Rebar.
My applications include Webmachine, Riak, and a few applications of my own devising. So far, I have been running Rebar successfully in the application root directory. But the Rebar bootstrap program suggests that there may be a better way. E.g.:
"You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps."
I can think of several ways to do this. But I'm wondering:
Is there is a preferred convention: e.g., placing Rebar in an .erlang file, /usr/local/bin, etc., etc.?
Many thanks,
LRP
I keep a copy in /usr/local/bin, which I use when creating new apps. For example:
$ rebar create-app appid=myapp
All of my projects are built with rebar by placing the binary in the root directory of my project and referencing it locally in my Makefile as seen here. As of this writing, this seems to be the convention the community has adopted. For example, nitrogen, mochiweb, ibrowse, and erlydtl are all built this way.
Personally, I'm not a big fan of including the rebar binary with every project but I don't see a good alternative. It makes life easier for people that either don't have rebar in their path, or don't have an updated version in their path.
I suspect this is a temporary situation. Eventually the rebar project will start to have fewer commits, and we'll all agree to keep a copy in our path. At that point we can all stop including it. Of course, if your projects are only going to be used by you, this is a non-issue.