I implemented a ros package that depends on some other packages.
These packages depend on even more packages and so on...
How can I find out which packages are actually used when building and running nodes in my package?
(Except for looking at ALL the package.xml files manually, because there are multiple cases in which some packages are listed there but already deprecated and not actually used anymore)
So I'm looking for something like a tool/command/script that can list all actual package dependencies.
I think you can do this natively with rospack. To see everything a package depends on (including dependencies of dependencies) without duplicates, just do
rospack depends my_package
You can get it formatted with indents to see all dependency chains of each package (will include duplicates across chains if more than one package shares the same dependency):
rospack depends-indent my_package
And if you only wanted to know the immediate dependencies of your package, you can do:
rospack depends1 my_package
I'm not sure that addresses the problem you identify that it shouldn't identify deprecated dependencies, but if a package is still specifying a dependency explicitly in a package.xml, how is the system to know that isn't really a dependency? It'd be better to get those package.xml files up to date.
Related
I've been trying to get a bazel monorepo with typescript to work. I have a couple of requirements in mind.
I should be able to import local packages using #myworkspace/ instead of ../../../ and so on, without needing Bazel. This is mostly so I get autocomplete while I'm writing.
The #myworkspace/ package should be the same during development and build time but only Bazel-managed dependencies should be resolved on imports when running sandboxed. Just so I know if I've messed up the name of the package in the js_library rule.
There should only be one lock file for the whole project. All dependencies should be located at root/node_modules.
It should be possible to individually deploy node packages i.e. #myworkspace/myCloudFunction.
It should be possible to include local dependencies in packages that will deployed.
I'm new to Bazel and it seems like it requires some mentality changes when coming from the NPM ecosystem. After googling, I've managed to find something that works for points 1 and 2 (But I might be wrong). I've published the playground repo at https://github.com/vitorelourenco/bazelmono-ts (pretty much a copy from https://github.com/lokshunhung/bazel-ts-monorepo with some ideas I took from https://github.com/angular/angular)
My questions about points 3 and 4:
Say I want the lib Lodash available on package #myworkspace/cloudFunction that will be deployed to Google Cloud Functions. If I install Lodash in the #myworkspace/cloudFunction folder, then Lodash will be added to package.json but I'll have a second node_modules folder and a second yarn.lock file, I don't want that. But if I install it in root/, then Lodash will not be added to the dependencies listed on package.json located at #myworkspace/cloudFunction, and when I deploy it, it won't install. Is there a smart way to handle this issue?
Point 5 is very similar. Ideally, the final Bazel output would have the local dependencies bundled in and ready to use but I can't seem to figure out a way to do it yet. I've tried adding a pkg_npm rule to //packages/app in the playgroup repo but couldn't get it to include //packages/common in it.
I am trying to clean my application of unused bower dependencies.
Is there a possibility or a tool to find unused bower dependencies in an application?
Bower downloads the packages and store them in the bower downloads directory. It is up to you to refer to these scripts in your application. You can search your application for the specific directory to find out if a script from that directory is ever referred to.
If you are worried about the scripts you are loading and not using any functions from them, there are tools available depending on the technology/framework you use.
If you are worried about the injected dependencies which are hardly ever used in the modules, then you should search for tools specified by the technology/framework.
I am just starting to get to grips with Nix, so apologies if I missed the answer to my question in the docs.
I want to use Nix to setup a secure production machine with the minimal set of libraries and executables. I don't want any compilers or other build tools present because these can be security risks.
When I install some packages, it seems that they depend on only the minimum set of runtime dependencies. For example if I install apache-tomcat-8.0.23 then I get a Java runtime (JRE) and the pre-built JAR files comprising Tomcat.
On the other hand, some packages seem to include a full build toolchain as dependencies. Taking another Java-based example, when I install spark-1.4.0 Nix pulls down the Java development kit (JDK) which includes a compiler, and it also pulls the Maven build tool etc.
So, my questions are as follows:
Do Nix packages make any distinction between build and runtime dependencies?
Why do some packages appear to depend on build tools whereas others only need runtime? Is this all down to how the package author wrapped up the application?
If a package contains build dependencies that I don't want, is there anything that I, as the operator, can do about it except design my own alternative packaging for the same application?
Many thanks.
The runtime dependencies are a subset of the build-time dependencies that Nix determines automatically by scanning the generated output for the hash part of each build-time dependencies' store path. For example, if you build a package using the compiler /nix/store/abcdef...-foo-1.20, then Nix will scan all files in the generated output for the hash bit abcdef.... If that hash is found, then the output is assumed to reference the compiler in some way, so it's kepts as a runtime dependency. If that hash does not occur, however, then the generated output has no reference to the compiler and therefore cannot access it at runtime, so foo-1.20 is treated as a build-time-only dependency.
Some packages record large parts of their build environment for informational/debugging purposes. Perl, for example, stores every little detail about the tools used to compile it, so all those store paths end up being treated as runtime dependencies despite the fact that Perl doesn't actually need them at runtime, but Nix can't know: it just knows that the Perl store path references those tools. Now, Nixpkgs maintainers usually make an effort to clean that up, i.e. by pruning the logfile that contains all those store paths from the installation, etc., but for sure there are plenty of packages in the database still that haven't been optimized to that end yet.
Let's assume that you'd like to compile a version of openssh that does not depend on PAM. Then you can remove the build input from the expression by means of an override, i.e. you replace the pam argument that's normally passed to the openssh build function with null. To do that, store the following file in ~/.nixpkgs/config.nix
{
packageOverrides = super: let self = super.pkgs; in {
openssh-without-pam = super.openssh.override {
pam = null;
};
};
}
and now install that package by running:
$ nix-env -f "<nixpkgs>" -iA openssh-without-pam
I'm trying to create a nuget package for the localization of another package, and I'm following the satellite package approach.
I'm pretty sure to have followed these rules strictly, and the naming conventions as well, but as I download the satellite package from my nuget repo server, it's not adding the expected /it/ folder under the /lib/ folder of the main package.
The main files structure is the following
/lib/net45/myfile.dll
and the satellite package has
/lib/net45/it/myfile.resources.dll
I tried everything, and I double check my packages configurations with the AspNet.Mvc.5.1.1 package and its satellites. They're the same...
I'm wondering if the problem could be on the NuGet server (but sounds weird to me)?
The server version is v2.8.50126.400
UPDATE
So it really seems to be the Server, as if I use a local path (C:...) as repo source, the packages act as expected.
Anyway I've just used the NuGet.Server package to create the server, there's some particular configuration I missed?
The problem was the NuGet.Server .
There's a field missing during the serialization of the feed, the Language, that's why the official packages are working: on the official server the Language field IS serialized, that allow the NuGet client to move the resource assembly to the right folder under the main package's lib folder.
But on a private repository built with the NuGet.Server package this field is just missing.
I've applied a pull request on Codeplex, for the ones who have the same issue.
https://nuget.codeplex.com/SourceControl/network/forks/tanathos/nuget/contribution/6524
I am trying to use Bower to manage client side dependencies from a Java/JSP server side application.
It works and I can access client side libraries resolved via "bower install" as described in bower.json.
However, lots of unnecessary files are added to "bower_components" as declared by the dependencies used (tests, docs, examples, etc).
Q: Can I manually specify filters to include/exclude files from each dependency I declare in bower.json?
If this is not possible, it sounds like i need to resolve "bower install"'s output outside the webapp directory and create a separate (maven/grunt) copy task to create the js lib files structure I want - sounds tedious.
You can use bower-installer which allows you to copy only the files you want by specifying filters to include/exclude files from each dependency in bower.json