I tried to create a bintray repository. But no matter what I specify as repository type it always create a generic repository. Is this a bug?
In the documentations it states that you need to supply the type in the payload, as shown here: "type": "maven".
The possible types are (currently): maven, debian, conan, rpm, docker, npm, opkg, nuget, vagrant and generic (default).
Check that you have at least this minimal payload:
{
"name": "myMavenRepo",
"type": "maven",
"desc": "This repo is my greatest maven repo",
}
Related
I am using the package teamtnt/laravel-scout-tntsearch-driver and I wish to make a very small change to one of the files within teamtnt/tntsearch which is one of the packages dependencies.
Usually I would:
Create a fork of the package.
Add the repository into my composer.json as follows:
"repositories": [
{"type": "vcs", "url": "https://github.com/user/packagefork"}
],
Require/Upgrade the package to the correct version (usually dev-master) keeping the original name spacing and it all works fine.
However, with a dependency which is not directly included in my composer.json file, this does not seem to work. Do I need to fork both the base package, and the dependency package even though I do not need to change anything within the base?
I am hoping there is a simple way to do this, without having to fork each level.
This was actually quite simple. Not too sure why it did not work originally! Instructions below for anyone wondering:
Fork the package (i.e. GitHub)
Add the repo from your username, to your projects main composer.json as follows:
"repositories": [
{"type": "vcs", "url": "https://github.com/youruser/tntsearch"}
],
Edit the composer.json file within the new fork you created in step 1 (youruser/tntsearch) and create/add to the extras key:
"extra": {
"branch-alias": {
"dev-master": "2.0.x-dev"
}
}
This effectively allows you to install your dev-master version, but allow other packages where this is a dependency to request the 2.0 version (in this case). You do need to be careful in this case that you have forked the correct version and any upgrades are correctly managed later down the line, or things may break!
More info on composer alias here
Require/Upgrade the package using original package namespace, at the dev-master version.
composer require teamtnt/tntsearch:dev-master
The name spacing and package versions will remain the same as before your fork, but the edits from your fork will be pulled into your project instead.
I have a project which uses dependency having having version same as that of the project. So I would like to change the version only in one place and write something like below this in my package.json
{
"name": "my-child-app",
"version": "1.2.3",
"description": "My Application",
"dependencies": {
"my-parent-app": %npm_package_version%
}
}
Basically the child app is always supposed to have version in sync with the parent app. So any approach where I will have to change only one line (instead of two in usual scenario) when I have to upgrade to a newer parent-app would suffice.
Note: I am using frontend-maven-plugin to build the project as child-app is a module of Java Project. parent-app is also built in a same way but they are not in the same code repository so file referencing cannot be used.
I've been looking into building a go project into a debian package.
I've looked into dh-make-golang and I have a nice and shiny debian folder set up in my repository. When I try to use gbp buildpackage --git-pbuilder though it errors out due to all of my dependencies not being found. It seems that dh-make-golang ignores the vendor folder when it copies everything from my project's git repository, and I use govendor so all of my dependencies are in there.
How can I resolve this dependency issue and build the project as a .deb package properly? For reference, the error I am getting is:
src/github.com/project/project/project.go:15:2: cannot find package "google.golang.org/grpc/grpclog" in any of:
/usr/lib/go-1.7/src/google.golang.org/grpc/grpclog (from $GOROOT)
/tmp/project/obj-x86_64-linux-gnu/src/google.golang.org/grpc/grpclog (from $GOPATH)
Issue was a bug in dh-make-golang regarding importing vendor dependencies. It was just fixed today.
https://github.com/Debian/dh-make-golang/issues/46
Take a look at goxc - it can do this for you!
You simply need to add a .goxc.json to the root of your directory, that looks like this
{
"AppName": "my_app",
"ArtifactsDest": "downloads",
"Tasks": [
"interpolate-source"
"deb",
],
"BuildConstraints": "linux,amd64 windows,amd64 darwin,amd64 linux,arm",
"ResourcesInclude": "INSTALL*,README*,LICENSE*,config/*,static/*,templates/*",
"PackageVersion": "0.9.3",
"TaskSettings": {
"deb": {
"metadata": {
"description": "my app",
"maintainer": "me",
"maintainer-email": "me#example.com"
},
"metadata-deb": {
"Homepage": "https://example.com"
},
"other-mapped-files": {
"/": "debian/",
"/usr/share/something/static": "static/",
"/usr/share/something/templates": "templates/"
}
}
},
"ConfigVersion": "0.9"
}
Then run goxc and it'll do all the work for you.
At the company I'm currently working we've recently started to move our code into different private repositories so that it's more maintainable and reusable (and also to make it easier to open-source it later).
Every PHP repository is also a Composer package that can be required in our project whenever we need it.
At the moment there's an issue with this approach: every time we need a package that depends on other packages we need to specify those also in the root composer.json.
For example, let's say that the in the root composer.json we need to require two packages company\b and company\c, and that the package company\c needs another package company\d. Then the resulting root composer.json will look like this:
{
"require": {
"company/b": "dev-master",
"company/c": "dev-master",
"company/d": "dev-master"
},
"autoload": {
"psr-4": {
"Company\\" : "src\Company"
}
},
"repositories": [
{
"type": "vcs",
"url": "git#bitbucket.org:company/b.git"
},
{
"type": "vcs",
"url": "git#bitbucket.org:company/c.git"
},
{
"type": "vcs",
"url": "git#bitbucket.org:company/d.git"
}
]
}
Is there a way to avoid specifying nested dependencies in the root composer.json and use the ones specified in the composer.json in every package?
Edit:
Everything I stated before is valid only for the private packages. If a package, let's say company\b, needs a public package that can be found on Packagist then that dependency CAN be specified in the company\b composer.json and it will be imported.
As you correctly found out, only the root package can add repository metadata to the collection of known packages.
I would suggest you take a look at Satis to create a local Composer repository. This would only require you to add this single repository to all your composer.json files of all packages, and it will be used as an updatable source of knowledge about all your private repositories. You no longer have to add a list of Git repos everywhere.
I am successfully hosting around 120 internal packages for our IT enterprise that way. Take this as a sign that once you start splitting isolated tasks into a package, you will get more of them pretty fast.
Also note that it is important to take versioning seriously. Stop depending on branches - tag your software, make releases, use semantic versioning. If you don't, things will break at some point, and people will curse you (correct) or Composer (incorrect) for not working or messing things up.
After a quick search and a look at the Composer documentation I discovered that the repositories can only be specified in the root composer.json.
Additionally it's possible to specify in the root composer.json whether to allow or not development versions of the packages using:
"minimum-stability": "dev",
"prefer-stable": true
Also this issue on GitHub was really useful.
I've probably misunderstood the docs (https://getcomposer.org) but is it possible to optimise the syntax for composer when including private repos. Ultimately; I want to step away from listing every repository and vendor pair when the vendor is the same...
In my projects composer.json I've got:
"repositories": [{
"type": "vcs",
"url": "git#bitbucket.org:{vendor}/{repo1}.git"
},{
"type": "vcs",
"url": "git#bitbucket.org:{vendor}/{repo2}.git"
},{
"type": "vcs",
"url": "git#bitbucket.org:{vendor}/{repo3}.git"
}]
...
"require": {
"{vendor}/{repo1}": "dev-master",
"{vendor}/{repo2}": "dev-master",
"{vendor}/{repo3}": "dev-master"
}
I figured; as the repositories is an array, then composer would search the repositories for a vendor/repo pair (or something) or if the vendor matches the vendor part of the repository url. It seems syntax heavy for a slight change...
But now I've confused myself by looking at package.json examples :s
Any kicks in the right direction would be great!
A repository does not have to have the same vendor/package name in every branch or tag - the name can change. So adding a repository simply extends the amount of knowledge Composer has about existing packages, while adding package names in require explicitly pinpoints them wherever they may be located.
If you use more than a handful of private repositories, I'd strongly suggest you create a packagist-like repository with either "Packagist", "Satis" or "Toran Proxy". That way you'd only add that one repo to all your composer.json files (not repeating all your private repos all over the place) and the packages you want to use. This greatly reduces the redundancy you feel, because you'd only deal with the package names everywhere, and with the private repository locations in the configuration file of your central repo solution.