Given a Bower package, I want to know how often people have installed it using Bower. Is that posible?
P.S. All that I found is a list of most populars packages and
ratings.
P.S.S. I know, that, for example, npm, provides kind of downloads stats (see it for a gulp-concat-css).
EDIT: The registry API no longer provides the number of hits per package.
The Bower registry keeps the number of "hits" per package which is actually the number of times a GET request for this package was sent to the registry. Since the Bower registry is only providing metadata (package lookup) and the downloads are done from somewhere else (Github), the number of hits does not reflect the actual number of download.
You can get the number of hits for a certain package by calling the registry API, for example: https://bower.herokuapp.com/packages/jquery
In additions Bower is collecting usage statistics from the Bower CLI. Stats are collected using Google analytics and are the source of what you see in http://bower.io/stats/.
Currently you can see the stats for the top packages but it seems that there are plans to allow getting stats per package. Take a look at Bower issue 1164 and the Bower stats Github repo for more info.
Related
I'm working in an Erlang environment. I'm looking to establish a dependency manager so that our build server can publish binaries for reuse instead of using source code dependencies. The Hexpm GitHub project implies that it is possible to run it outside of the hex.pm website, but I don't see any instructions for doing so. Specifically, I would like my build server to be able to publish packages either directly (via the filesystem) or via rebar3, and for subsequent rebar3 builds to be able to use those published packages
Is it possible to run Hex on my own server?
If so, where would I find some documentation on how to set it up (or provide the instructions directly)?
If you look at https://github.com/hexpm/hex_web there are instructions in the README.md for both installing and running it. It's a phoenix application, so it should all be relatively familiar ground if you've looked at the phoenix framework before.
As for getting rebar3 to work with your installation, there is documentation here as to the config values to use for setting the URLs to use for hex packages: http://www.rebar3.org/docs/hex-package-management.
HTH.
I use Vagrant + virtualBox and a Debian 8 / Ubuntu image for my development environments.
I want to use nix for provisioning, but I can't get nixOS to work completely right (ie. with networking, provisioning...), but I'd more than happy to switch. So I'm falling back to nix + Debian 8 or nix + Ubuntu to mimic the production server.
I can't quite get the differences between user packages and system packages and what is preferable to use in in my context, in order to be able to reuse that into a production server.
Should I install packages with nix -i, or edit the configuration.nix file ?
Whether you should install packages into the system profile or into a user profile depends on what you'd like to achieve. There is no single right answer. Instead, both types of installing packages have different pros and cons.
System packages are defined in a global configuration file that typically resides in /etc/nixos/configuration.nix. Users other than root can typically not edit that file and thus cannot add or remove packages from the list. Packages defined in there will be installed as part of nixos-rebuild and they'll be available in $PATH to every user of your system. If any of those packages don't compile for some reason, however, then you cannot rebuild your system, i.e. you may find yourself in a situation where you cannot update your kernel because, say, nano doesn't compile. People who follow the master branch of the Nixpkgs git repository may experience this problem frequently, but it doesn't happen so much for users of the unstable or the release-x.y channels.
User packages can be installed, updated, and de-installed by any user on your system without the need for super-user privileges. One user's packages will not be visible to another user (unless she makes a conscious effort to import them into $PATH). Thus, it's possible for two users to install two different versions of the same package.
If a user does not regularly update her profile, then you'll accumulate old packages in your Nix store that cannot be garbage collected. This may be a problem or a feature, depending on how you look at it. System packages, on the other hand, are all updated every time you update the system, so those tend to have a smaller disk space footprint.
Personally, I prefer to keep my system profile as small as possible; I install packages mostly into user profiles with nix-env. I know many people, however, who do the exact opposite and we all get along fine. :-)
We use travis-ci for continuous integration. I'm troubled by the fact that our build process takes too long (~30 minutes). We depend on several Ubuntu packages which we fetch using apt-get, among others python-pandas.
We also have some of our own debs which we fetch over HTTPS and dpkg install. Finally, we have several pip/pypi requirements, such as Django, Flask, Werkzeug, numpy, pycrypto, selenium.
It would be nice to be able to at least pre-package some of these requirements. Does travis support something like this? How can I prepackage some of these requirements? Is it possible to build a custom travis base VM and start the build from there (perhaps using docker)? Especially the apt-get requirements from the default Ubuntu precise repository as well as the pip requirements should be easy to include.
So while this question is already answered, it's doesn't actually provide a solution path. You can use cache directives in travis to cache your built packages for future travis runs.
cache:
directories:
- $HOME/.pip-cache/
- $HOME/virtualenv/python2.7
install:
- pip install -r requirements.txt --download-cache "$HOME/.pip-cache"
Now your package content is saved for your next travis build. You can similarly store slow-to-retrieve resources in other directories and cache them.
Currently Travis-CI doesn't support such a feature. There are related issues currently open though such as custom VMs, running Docker in an OpenVz container - (Spotify seems to have a somewhat working example links in this issue), using Linux Containers (LXC), using KVM.
Some of those have workarounds mentioned in the issues, I'd give those a try until something more substantial is supported by Travis-CI. I'd also suggest reaching out to Travis-CI support and see if they have any suggestions (maybe there's something coming out soon that could help).
I am developing a sample app using MEAN stack and tried to install BreezeJS via bower. But it downloads whole bunch of .NET related stuff. I read from the BreezeJS documentation, that it can be used in Non-MS backends.
Any hints on how can I use bower to install breezeJS or do I have to download files manually.
Update 26 May 2014
There is now an official breezejs bower package for client assets. Install from a terminal/command window with
bower install breezejs
Case matters! Be sure to spell "breezejs" in all lowercase.
This package contains the core JavaScript distribution files PLUS
adapters - the officially supported breeze adapters in the core, including the mongo client adapter
labs - the currently "approved" breeze.labs
HTH
p.s.: You still use nmp to install the breeze-mongodb module on your node server.
Original
Feel your pain. It's helpful to our priority setting to know that this matters to you.
We are in the midst of doing two things about this.
refactoring the github repository into multiple repos to be more sensitive to technology preferences.
working with the current keepers of the Breeze bower repos to refactor accordingly; actually, they have offered to let us take over ... and we will; we just need a little more time.
Until then, I'm afraid you'll have to grab the JavaScript files from github yourself. Fortunately there are not many of them.
Breeze client JavaScript files are in the build folder of the breeze.js repo.
Breeze Labs for JS clients are in the breeze.js.labs repo.
The breeze-mongodb module for your node server you can install with npm.
I'm new to Zend Framework 2.0, after reading the documentation I know that we can install Zend via some package managers as Pyrus, Composer. But I don't know which package manager should I choose? Please explain to me some differences between them, thank you for help!
Pyrus is basically PEAR2, and needs the end developer of a package to configure a pyrus distribution channel to make packages public.
Composer is backed by the main packagist.org repository, with the availability of own channels through satis if necessary.
Pyrus is mantained, but has not much activity on its main repository, composer is much more active.
Composer is the most used package manager for PHP currently available. Most ZF2 modules currently support it and don't support Pyrus, so I strongly suggest you to get used to it.
Related: ZF2 + doctrine without composer (an example of how this tool is becoming necessary).
In addition to Ocramius' explanation:
Pyrus is not PEAR2. Pyrus is a standalone tool that can install packages from any PEAR-compatible channel, including pear.php.net and pear2.php.net.
Pyrus is able to install and compile PECL packages (PHP extensions).
Publishing a package yourself is easier with composer. You only need one single file in your git repository; Composer can install directly from there. Pyrus on the other hand needs a bunch of XML files you can't hand-generate - so you have to use a channel server software like Pirum.