Suppose you have
ssh://git#example.com/project/foo
ssh://git#example.com/project/bar
ssh://git#example.com/project/baz
And you want to add project/foo, project/bar, project/baz as dependencies. Configuring each with composer config repositories.project/foo git ssh://git#example.com/project/foo doesn't seem very efficient.
There is no shortcut for packages with the same prefix - each repository must be defined separately, and in this case one repository can contain only one package.
If you have many private packages, you should probably switch to Satis or Private Packagist.
Related
i was having issues on how vendor take too much place. Since my host has a limit on number of files and folders (INODES). So i found a solution to use one Vendor for multiple project in laravel through the following link : Using one Vendor Folder for Multiple Projects in Laravel 5.2.
In the following lines I put the vendor in projectA, then link the others projects to it.
In projectA everything works well when i do php artisan migrate:fresh --seed
When i try the same thing to projectB for example, the above command works till it arrives where the seeders should be executed. There, some error occur due to the fact that the command is trying to launch a seeder of projectA in the projectB as shown in the following screenshot.
Seeder Error Screenshot
So i want to know if there's a way to make the seeder separately.
I tried to create a symlink on the composer.json file as it was done for the vendor folder, but it doesn't work.
I'm using Laravel 8
I thínk this is a terrible idea, except in the case that both projects share exact same codebase.
Composer use composer.json as you know. How does your B project composer file determines how to resolve PSR4 autoload entries in Laravel, If it is symlinked to A project? That is probably the reason why your seed command is trying to locate Classes in A project.
Composer is clever enough to cache downloaded packages and reuse them, but I think that every project has its own dependencies and state, which is maintained by composer.json in the first case and composer.lock on the state case.
What happen if you update composer in A but not in B, will B work?
And last, composer autoload file reference all satisfied dependencies in your project, and in this case that (unique) autoload file will be loaded in both projects but what happen if your required packages are not exactly the same? ie You have Laravel Debug Bar in one project but not in the other. The autoload generated file will reference that package that will not exist on your other project.
Is not this the way composer work? Am I wrong?
In Composer the Vendor Directory (vendor in the project tree by default) is per project.
You ask about how to use one vendor folder for different projects.
Now first of all, this is absolutely not what Composer expects nor how it works. See Manuel Glez answer. In short a terrible idea.
When it comes to Composer, the place to share the actual PHP code across projects is not in the vendor directory but in repositories.
And as long as the dependencies are compatible, you could make one project depend on another and use its vendor/<vendor>/<name> folders as repositories. The remarks in Manuel Glez answer are still the same, this need to be same compatible versions across the board.
But to give the example, see Composer Path Repository which has this layout:
...
├── apps
│ └── my-app
│ └── composer.json
├── packages
│ └── my-package
│ └── composer.json
...
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package"
}
]
}
It can be adopted for each ../../project/A/vendor/<pkg-vendor>/<pkg-name> in ../../project/B/composer.json so that the vendor folder in project/A can act as a path repository for project/B.
As dependencies composer.json files normally do not contain the version, the documented remarks about repositories.options.versions apply:
When the version cannot be inferred from the local VCS repository, or when you want to override the version, you can use the versions option when declaring the repository:
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package",
"options": {
"versions": {
"my/package": "4.2-dev"
}
}
}
]
}
To prevent the duplication of the files the default strategy for Composer is to symlink the package directories. Ensure it works, then you only have one symbolic link per dependency in project B.
Okay how cool is that? Well IMHO while you still give up much of what Composer can do for you for dependency management, this at least makes use of local Composer repositories which I'd recommend for sharing instead of completely symlinking the overall vendor folder. Each project still have its own vendor/composer setup and overall what is done is much more well defined and in line with Composer itself.
Whether this works or not depends on the individual case. Key point here is as these local repositories only provide a single version per each package, you can only have that one. So these versions must all be version compatible on API level.
The system where it runs needs to support (relative) symbolic links, this should be commonly available for the situation described.
You could then automate the production of the repositories configuration and adopt it to the file-system layout. You could even generate the repositories and update them in the global configuration file so that each project would automatically prefer those packages from local.
$ echo "$(composer config --global home)/config.json"
/home/user/.config/composer/config.json
(compare: COMPOSER_HOME/config.json (Composer docs))
Take care all projects and their dependencies have a portable path-profile and then I'd say this should be quite straight forward shell processing.
To obtain the actual versions of the dependencies installed check per each vendor folder inside vendor/composer/*installed* files.
$ (echo "PACKAGE VERSION"; find .. -type f -path '*/vendor/composer/installed.json' -exec jq -r '.packages[] | .name + " " + .version_normalized ' {} \; | sort -u | sort -k 1b,2V) | cols
PACKAGE VERSION
composer/ca-bundle 1.3.2.0
composer/composer 2.3.7.0
composer/metadata-minifier 1.0.0.0
composer/pcre 3.0.0.0
composer/semver 3.3.2.0
composer/spdx-licenses 1.5.7.0
composer/xdebug-handler 3.0.3.0
...
phar-io/manifest 1.0.1.0
phar-io/manifest 1.0.3.0
phar-io/manifest 2.0.1.0
phar-io/manifest 2.0.3.0
...
(very old installations don't have the packages keyword, you'll likely want to filter)
Finally you may want to have something to smoke-test the setup easily so that you can have guards against the dependency incompatibility problems when you take notice of them.
I use pip/poetry/Pipenv to install dependencies depending on what is less broken and painful in a given month. I have a private pypi compatible repo and have many dependencies on public pypi.
I can see that when a dependency is missing from the private repo or if the private repo is misconfigured, pip will try to get the dependency from public pypi, which at best is the wrong package at worst is malicious code as describe here.
Is there any way to tell pip, poetry and/or Pipenv which repository it should use on a per package basis without fallback behaviors?
It looks like registering all my private package names on public pypi is considered name squatting and is against pypi's rules.
This is different from the various questions on how to install from a private repository. The question is how to force the package manager to only install a package from the specified repository when there are unavoidably two or more repositories.
You can specify whatever package index you like in pipenv. This is an example from the advanced usage docs from pipenv. More usage and separate use cases can be found here
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"
[[source]]
url = "http://pypi.home.kennethreitz.org/simple"
verify_ssl = false
name = "home"
[dev-packages]
[packages]
requests = {version="*", index="home"}
maya = {version="*", index="pypi"}
records = "*"
The location: github.com/elastic/beats
The mod file: github.com/elastic/beats/go.mod
The module name: github.com/elastic/beats/v7
The tag: v7.10.2
What LoTR incantation of go get to I have to run to get a little dependency update action?
This will update to latest minor.patch version of v7:
go get github.com/elastic/beats/v7
or if you want a specific version to update/downgrade to:
go get github.com/elastic/beats/v7#v7.10.2
Adding the -u flag will additionally update the dependencies of github.com/elastic/beats/v7:
go get -u github.com/elastic/beats/v7
The argument list passed to go get should generally be a list of package paths or patterns, not just a module path.
For example, you might invoke:
go get -d github.com/elastic/beats/v7/libbeat/beat#latest
in order to obtain the latest version of package …/libbeat/beat and also download any transitive dependencies needed for that package.
(You can pass just a module path, and that should also update the version of the dependency module overall, but it will not download source code or module checksums for transitive dependencies that may be needed in order to build the updated package. go get does not in general know which transitive dependencies will be relevant to the commands that you plan to invoke after it, and it does not do extra work to speculatively identify relevant dependencies.)
I am trying to extend a custom github repo installed via:
// package.json
"my-custom-rule": "mikebarron/custom-rules#custom-branch"
how to apply this rule in extends?
extends: ["mikebarron/custom-rules"]
just giving "custom-rules" wont work.
Discovered the solution, looks like I needed to follow the "main" on "package.json" file, need to have "custom-rules" in this case.
I am having issues using google.golang.org/grpc from vendor directory and I get the below error
cannot use &metadata.HeaderMD (type *"google.golang.org/grpc/metadata".MD) as type *"project1/vendor/google.golang.org/grpc/metadata".MD in argument to grpc.Header
I get the error though I am using the necessary version of the package which I copied from my gopath. But, when I delete the golang.google.org/grpc folder from vendor my project fetches the dependency from gopath and it works fine though the one gopath is a copy of when I have in vendor directory and every other library in vendor directory works fine except grpc.
When you created project1/vendor/google.golang.org/grpc, it means that for packages under project1/..., an import of google.golang.org/gprc/... will be transparently remapped to the vendor version.
Any packages outside of project1 will continue to import the non-vendored google.golang.org/grpc/... packages. While the vendored package might be a copy of the upstream, Go treats them as independent packages. So the types they contain are not equivalent.
What has most likely happened is that one of your non-vendored dependencies imports the grpc package and uses its types in its public API. When you make use of that API from project1, you get the upstream type which can't be assigned to variables using the vendored types.
There's two possible solutions to this problem:
Vendor all of your dependencies that make use of what you've already vendored.
If you're using Go >= 1.11, switch to the newer Go module build system. This will let you continue to control when you upgrade your dependencies without having the project1/vendor/... tree to confuse the type system.