Is there a way to self-host a DUB registry? - d

I am building multiple projects for a client and they tend to have common code that I've factored out into separate projects. I'm trying to use DUB to organize all of this, but so far I can't figure out how to add these common projects as dependencies without publishing them on a site like github and registering them in DUB's public registry. Publishing these things would either violate my contract or put uninteresting spam in the DUB registry (or both). Is there any way I can operate my own DUB registry on a private server, and have it graph all of the usual public projects plus a handful of private ones in LAN-accessible git repos?
This would save me from having to make a lot of git submodules. :)
Thanks.

You can self host a dub registry by using your own --hostname parameter on dub-registry and providing your own --registry parameter on dub.
Alternatively, you can just use your packages locally (or remotely, if packages are placed on network drive). Dub wiki page "Cookbook" explains how to work with packages that are not in registry: https://github.com/dlang/dub/wiki/Cookbook#working-with-submodules-or-packages-that-are-not-in-the-registry
Working with submodules or packages that are not in the registry
It is a common practice to either have a project as a git submodule of
a master project, or to use an unregistered project as a dependency
for development. In this setup, setting the project to depend on a
project at a given path, rather than looking up the repository, can
come handy. Here's an example of such a package:
{
"name": "dlang-org",
"dependencies": {
"libddoc": { "path": "./libddoc" },
"libdparse": { "path": "./libdparse" }
}
}
Another possibility is to add-local a package. This is particular useful
during development, when you want to test a package with some
libraries using that package.
dub add-local myrepo
dub list

Related

Do I need to stage the 'vcpkg' directory to git

I am new to c++ development environment from javascript dev environment. Comparing to javascript package management, c++ is complicated. I found vcpkg that like npm for cpp.
The question :- When it comes to 'vcpkg' do I need to stage all files (to git) that contains in /vcpkg directory. Or just add it to .gitignore.
The project diretory :-
The /vcpkg directory contains a lot of files, that why I asked.
You shouldn't upload the dependencies to your repository. The correct thing to do is to use vcpkg in manifest mode. This way vcpkg.json package will be used to keep track of your dependencies. Every time you install or remove a package vcpkg.json will be automatically updated eliminating the need to upload your dependencies to your repository. You only need to upload vcpkg.json to your repository which is much faster. It also has many more advantages, take a look at https://vcpkg.readthedocs.io/en/latest/users/manifests/

Can you add CLI tools to a Cloud Foundry app?

Terribly sorry if this is an obvious question. But I have a webapp that relies on a CLI tool to get it to work. I was wondering if there was a way I could specify this without using a custom buildpack. And how to go about doing this if possible
Any help on this would be great, thanks
Can you add CLI tools to a Cloud Foundry app?
It's not possible to directly install things with apt or apt-get. Your app runs as an unprivileged user and is unable to run those tools to install things.
This leaves you with a couple options:
Get the binary and bundle it with your app. Some people (no judgement from me though) would say that your app is responsible for bringing everything it needs to run anyway, so you should be doing this already.
Twelve-factor apps also do not rely on the implicit existence of any system tools. Examples include shelling out to ImageMagick or curl. [1]
This path works well for dependencies that are small or self contained, like statically built Go apps. If your app need shared libraries or other resources to function, you need to bundle those with your app too. It's also not great if the size of what you bundle is large. Everything you bundle will be pushed up with the app, so it can slow down your pushes. You are also responsible for tracking updates and making sure that you have the latest, bug free & security patched binaries & libraries.
The general steps for doing this are:
Create a folder like binaries/ under the root of your app, with subfolders of bin/ and lib/.
Place all your binaries under binaries/bin and any shared libraries they require under binaries/lib.
Add a .profile file at the root of your app. This will be sourced prior to your app starting so it will put any binaries you bundle on the path and add libraries to the search path.
In .profile put the following:
export PATH=$HOME/binaries/bin:$PATH
export LD_LIBRARY_PATH=$HOME/binaries/lib:$LD_LIBRARY_PATH
That should be it. Just push your app with all the new files.
Another easier option, is to use the Apt buildpack [2]. This buildpack can install required dependencies using apt. You just need to add an apt.yml file to the root of your app & run your app with multi-buildpacks (apt buildpack first, then your normal buildpack).
The main benefit of doing this is that you don't have to manage the dependencies. The apt buildpack will automatically install them from the repo you tell it to use, so it'll pick up new versions from there as well. This is good if what you need to install has a lot of dependencies, particularly sensitive dependencies (like openssl) or dependencies that get updated/patched often like other language runtimes (Python, Perl, Ruby, etc...).
Other benefits. It's easier because the buildpack takes care of adjusting PATH & LD_LIBRARY_PATH. It also makes the app size smaller so pushes are faster.
The downsides of this option are that the apt-buildpack is not an official buildpack (it's community maintained). It also works best when you have Internet access, so it can download binaries from the Internet, although you can work around this by using an internal repo.
There's a couple other options as well, but I wouldn't recommend them unless both options above are definitely not going to work for you.
Use Docker. You can set up your own Docker container with all the dependencies you need, plus your app code and cf push the Docker image to CF. The downside of this is that your lose the advantages of using buildpacks, so you're back to building and managing Docker images and all the required dependencies of your app all on your own.
You could create your own custom buildpack and supply the dependencies that way. I don't see any reason you'd want to do this though. It's a decent bit of work and in the end, you'd have something that's just more brittle and less flexible than Apt Buildpack.
It's technically possible to ship your own rootfs, but you really really shouldn't (I'm just including this to be thorough). This is the base file system that's used by all apps on CF. Doing this has a lot of drawbacks though, chiefly being that it's difficult. It also applies to all apps on the foundation, can bloat the size of the rootfs, and makes a larger attack surface for anything using the rootfs (i.e. all apps).
Hope that helps!
[1] https://12factor.net/dependencies
[2] https://github.com/cloudfoundry/apt-buildpack

Can I specify Git URLs as dependencies in Buck?

I am using Buck to build a C++ project.
I would like to add a Git URL (e.g. git#github.com:owner/project.git) as a dependency so that a build can automatically pull down a library from GitHub. I took a look at remote_file, but that only seems to work for HTTP, HTTPS and Maven.
Does Buck provide this functionality out-of-the-box?
If so, is it possible to specify a specific commit hash or tag?
Buck does not support remote Git URLs.
Your options are:
Copy the code manually into your project
Use an equivalent .zip URL (GitHub gives you these)
Use submodules, such as in this example
Use a package manager that supports Buck, such as Buckaroo

Maven dependencies for Clojure libraries on GitHub

I'm developing some applications in Clojure + Java using Eclipse and Maven with m2eclipse.
This works great when my dependencies are in a Maven repository. However there are some libraries that I would like to use that aren't in any repository - e.g. small open source Clojure libraries hosted on GitHub.
These projects typically have a build.xml or a project.clj but not a pom.xml.
Is there a any way to set up Maven to handle these dependencies automatically? Or do I need to manually download and build all of these?
Unfortunately no, you'll either have to:
find a repository containing those libraries
manually add these to your repository using mvn install (and if you're kind enough, ask for those to be published in the central maven repo)
ask the developers if they would be so kind to propose a mavenized version and publish it in some maven repository
Clojure libraries often provide their artifacts in clojars, you might solve your issues just by adding it as a repository in your pom.xml.
Another option available when integrating leiningen and maven builds is to automatically generate a POM out of a project.clj via lein pom
This would allow to include the libraries in your build as long as you checked them out locally.

Creating a submodule in a git project

I have a Django project and it's currently hosted in GitHub and it's private. I'm looking to move many useful parts of it into an open-source project. I think I need to use a 'submodule' thing, but unfortunately I have no idea how to operate these.
Please can someone help me :)
Joe
move many useful parts of it into an open-source project.
That means extract one or several directories (and their associated history) into several independant git repositories, each one pushed to a public GitHub repo.
To extract a sub-directory from a Git repo, see the filter-branch command in this SO question
(also in:
"Howto extract a git subdirectory and make a submodule out of it?"
Detach subdirectory into separate Git repository
)
to reference those new repositories, reference them in your original private repo to see them again directly from your current Django project: see true nature of submodules.