May I ask you for some little thing that might change the (development) world? Would you please like to introduce a folder, where people might put their dependency.yml file - this is an effort to finally stop the spreading cancer of "put one more config file into the project root".
I would like to suggest to call that folder simply "config" - all the projects and tools out there should have no problem with that. Optionally there could be one top level config file called "config.rc" - this file points to the actual config dir if it is not "config".
It would be verrry nice if one service just starts with that and hopefully all the others will follow and it will become a defacto standard. The pollution of the top level project directories really must stop.
Thank you!
Thanks again!
No but seriously, I don't think this mess of config files in the project root is really a big deal. I already grouped the interesting stuff under /src. If it is a big deal, then lets hash out an RFC that covers the general concept of "configuration" once and for all and be done with it.
Dependency CI works like Travis CI but for the dependencies of your application, checking them for license and status issues every time you push to GitHub.
I've written a up a post on medium with more details: https://medium.com/@teabass/introducing-dependency-ci-e859fa...
It’s 100% free for open source projects and there’s a 14 day free trial for checking private github repositories too.
As a side note, I recommend creating a separate github account when granting permission to this kind of 3rd party. Don't grant them full read/write on your repos, create an account that's temporarily admin, then make that account read only.
This is immensely useful, especially to the maintainers of libraries.
In order for them to be tested, dependent objects have to declare their testability using the autopkgtest [2] interface.
[2] https://people.debian.org/~mpitt/autopkgtest/README.package-...
Debian's CI focuses on actual run-time testing, specifically what it calls "as-installed" testing (as opposed to build-time testing). You don't test a specific build result, but whatever is installed in $PATH, $LD_LIBRARY_PATH, and so on.
Because the tested objects also use the as-installed dependencies -- libraries, modules, etc. -- whenever one of the dependencies changes, the dependents can automatically be re-tested for compatibility.
Everyone else - Is this a general problem with people locking these (very cool) tools to GitHub? Is there a generalised solution to the problem of source control integration?
Since each hosting service has a different API, each integration needs to be built individually. And it makes sense to integrate with GitHub first because it’s the most popular repo host.
No conf required other than your normal requirements.txt, sends you a PR whenever there are new versions available. Cracking stuff.
Github's pricing model means that lots of people can't use it for private repos - 'per repo' pricing isn't fun if you prefer lots of small repos.
I'm working on VersionEye since a couple years, it's a similar project and I open sourced it last week: https://blog.versioneye.com/2016/06/28/versioneye-goes-open-.... I'm following Andrews activities since a while and like what he did with libraries.io. Great job! As both projects have a big overlap and are open source now I'm open for collaboration :)
We also use it for Cloud Foundry. It's fairly robust.
I work for Pivotal, but not on LF.
This way everything is under my control. What good is it if I'm told my dependencies has been deleted? And then I what? Copy my old dep from my dev machine to a cloned repo and point to that? Isn't that the same step as above?
Or maybe I just don't get it.
Typically, you can define your dependencies in a file specific to a certain package manager. NPM uses `package.json`, RubyGems uses `Gemfile`, etc.
It is a reasonable practice to "vendor in" your dependencies, as you suggest. But given the declaration of your dependencies in some manifest file, Dependency CI can give you valuable insights.
Even more interesting would be something that would attempt to force code coverage analysis on projects that use a standard testing framework, have a certain amount of tests present, but don't have CC configured in their project.
At first I was thinking that is what this service did but it doesn't appear to be the case.
DepdendencyCI already did better than us in that regard and it seems like they are doing an an all-around great job (I especially like the multi language support)! :)
Hattip to the team!
Bug?
