Can anyone please explain what exactly is the difference between depends and build-depends?
Somewhere, I read in build-depends, we add packages required for building our package. As per my understanding, anything needed for building my executable/library should be added here. It may include tools like cmake as well as other dependencies.
And in depends, we put dependencies needed for installation. I don't understand this.
Can anyone please explain?
Thank you.
"build-depends" is used to list down the packages which are required to build / create the debian package.
"Depends" lists out the packages which are used for the functioning of the package i.e. when dpkg -i <package_name> is run, it will first install the packages listed under "Depends" and then install the final package as the final package is exporting / using the functionality of the packages defined in "Depends".
Related
Within my Conda environment with Python 3.6.9, I've installed AllenNLP 9.2.0. I tried to install AllenNLP Server following the instruction from https://github.com/allenai/allennlp-server by running pip install --editable .
However, the installation procedure never finished as the compatibility checks with several modules, e.g. pip is looking at multiple versions of tqdm to determine which version is compatible with other requirements. This could take a while. Collecting tqdm>=4.19
Does anybody know what happens here? Should I add more restrictions to steup.py in AllenNLP server? However, there is any code included in such file.
Thanks a lot for your help.
I just tried it with AllenNLP 2.0.1 (the latest), and while it takes a long time, it does eventually resolve the packages.
That said, I would recommend two things:
Use Python 3.8 instead.
If it still doesn't work, specify a version of tqdm tightly in the requirements. My version automatically picked tqdm==4.56.2, just or reference.
I'm working on a mysql installation script for our system, to be part of an automated deployment system. Looking through previous installations, it seems like we might have been loading redundant packages, some via apt some via pip. Looking at Ansible roles for mysql also reveals slightly differing default package lists (e.g. this and this). So I thought I would look up what these packages actually do---only to find that I couldn't find anything informative.
The definitive list, presumably, is this one from MySQL. However I find descriptions like "MySQL database common files" not very helpful. Common to what?
So my general question: is there a better summary of what the different packages do? And if the answer to that is no, then at least can anybody tell me when/why I would want to explicitly install these packages (which were included in my legacy scripts):
mysql-common
libmysqlclient20
libmysqlclient-dev
and in the case of the last two, why I would install one or both of those, vs simply installing mysql-client (the "meta" client installer)?
I am reading a book (AngularJS) and currently I am on the step where I need to install Karma Test runner and Jasmine plugin. I actually understand (because it is well described) every step of the installation, but getting stuck on the Package JSON file.
The problem is, that I have no ANY idea what is this file for, where to find it, where the file should be downloaded from and placed in. I cannot find any useful information, where it is explained, why do I need this file and where do get it from.
I found some articles explaining how to create the file, however I don't know what to write in it's version or name and so on...
Could anyone help me with this some step by step explanation about the file, or share a reference where I can get little more information about it.
Thanks in advance!
The package.json file is metadata that describes a Node Package Mananger package for the benefit of other people downloading that package. It should be placed in the root directory of your project. It lists the sort of information you would expect to find when searching for a package, such as title, description, author, version number etc. A full explanation can be found here
Most importantly it also lists the production and development dependencies required for your module to run, any npm package listed here would be automtically downloaded with the package (dev dependencies downloaded when --dev flag set). Dependencies required for your package to run would be listed under "dependencies", dependencies required for developers working on your code would be listed under "devDependencies"
If you are not planning on releasing your work as a node module for others to download then you don't need to worry about the majority of the fields because
nobody will ever see it.
However the package.json file is very useful even if you aren't planning on releasing as a package, because it provides an automated way of fetching dependencies for your project.
Any listed dependencies will be installed automatically into a folder called "node_modules" in the root of your project by Visual Studio 2013 update 3 onwards.
Running the command "npm install" against the root of your project would also have the same effect, automatically fetching and installing any listed dependencies.
So for example to provide an automated way for developers working on your code to fetch modules such as Karma you would have the following in your package.json:
// package.json
{
"devDependencies": {
"karma": "^0.13.0",
"karma-chrome-launcher": "^0.23",
"karma-jasmine": "0.3.8"
}
}
Normally a bower.json file specifies some dependencies, but these are typically expressed so that they allow a range of versions of a bower package to be used (e.g. >=1.0, which means anything higher than version 1.0).
I have an automated process which needs to find what version of a bower package is actually installed on this system right now.
How can I find this out programmatically (just the version itself), ideally using standard Unix command line tools / the bower command?
bower info <thepackagename> does not show this - it shows information about what is currently available from the bower repository (for example, even if I do bower info apackageIdonthaveinstalled it will still show a valid JSON structure containing a version number).
cat bower_components/thepackagename/bower.json | node_modules/json/lib/json.js version works for some packages (assuming the npm package json is installed), but not all (e.g. jquery 2.2.0's bower package does not contain a bower.json).
Here's a grep command to do that:
grep "version\"\:" bower_components/thepackagename/.bower.json
Also, a command to see versions of all bower components for the project - this list can be a handy CI artefact:
grep "version\"\:" bower_components/*/.bower.json
Have you ever tried "bower list --json=0 --offline".
It would list all bower packages info.
The best approach I've now found, which seems to work for every package I've come across so far, is:
cat bower_components/thepackagename/.bower.json | node_modules/json/lib/json.js version
(note the extra . in .bower.json).
It would appear that bower stores some metadata about the installed package in .bower.json, and that includes the installed version.
The best I've come up with so far is:
bower list | grep jquery | perl -pe 's/.*jquery#(.*?) .*$/$1/'
(if, for example, the package I was interested in was jquery).
That's pretty ugly for a variety of reasons:
I have to repeat the package name (although this could probably be improved
with a better Perl script which filters lines too, I'm just being lazy).
bower list gets information about all installed packages, not just the one I'm interested in - the rest of the information is discarded.
bower list seems to require internet connectivity to check the registry, otherwise it fails.
Would be interested to see if this could be improved upon, particularly the last point.
I'm trying F# on OS X and I'm having trouble installing packages. My problem is to use MySQL.
I have downloaded Nuget and I can launch it. However, I didn't find any useful documentation about how to use it on the command line.
I managed to install MySQL.Data by doing
mono nuget.exe install MySql.Data
which downloaded it to my current repository. Is that normal? I was expecting it to be "installed" in a more central directory.
Moreover, when I try to require it, r "MySql.Data it doesn't work. It works if I set the include path properly by doing:
fsharpi --lib:MySql.Data.6.8.3/lib/net45
But that seems super heavy. Is there a way to add all the installed nuget in the path automatically?
Short answer: No.
Long answer: Yes, but it won't be what you hoped for.
It is possible to get NuGet to put installed library some specific place. On Mac OS, add the following to the end of ~/.config/NuGet/NuGet.Config
<configuration>
<config>
<add key="repositoryPath" value="/path/to/where/you/want/it/to/go" />
</config>
</configuration>
However, (a) NuGet still puts DLLs in different directories, so there is still no single place for fsharpi to find them. (b) Anyway fsharpi doesn't honor $MONO_PATH, Mono's canonical way to add to the DLL search path.
The closest I've come to a workable solution for fsharpi is:
Whenever you nuget a package, manually add it to MONO_PATH (say, in ~/.profile). E.g., supposing you told nuget to put stuff in /opt/nuget you would add:
export MONO_PATH=$MONO_PATH:/opt/nuget/MySql.Data.6.8.3/lib/net45
Whenever you run fsharpi, explicitly feed it $MONO_PATH:
fsharpi -I:$MONO_PATH
If you feel adventurous you could then patch the fsharpi script to automatically include $MONO_PATH.
I find that this is not worth the effort. Simply constructing a script that starts fsharpi with the options you need for whatever you're currently working on is a much more practical solution.
I'm an F# programmer on a Mac. My life is like an illicit love affair with someone married: I endure all the little slights because my heart leaves me no choice.
The most common use I see is
mono nuget.exe install mysql.data -OutputDirectory packages -ExcludeVersion
Which would install in your project's directory (generally you ignore the packages directory in your repository however and just restore it with a script) and you'd then find it at packages/MySql.Data/lib/net45
Downloading nuget to your repository is also common.
You can always write your own script to do the the fsharpi hookups you want, nuget has a lot of convention, so it's possible to pick the right dll from lib/*/ for your purposes
And it's possible to do it with an fsharp script, here's an fsx script that can be executed directly, it downloads nuget, installs from nuget, and then executes another script (with fake not fsharpi, but that's totally possible.