Composer doesn't seem to update a sub-package for me even though it fits the dependencies and an updated version is available.
> c depends sub-package
package1 requires sub-package (1.0.*)
package2 requires sub-package (1.0.*)
> c show sub-package
name : sub-package
versions : dev-master, 1.0.1, * 1.0.0
> c update
Nothing to install or update
It looks like 1.0.0 is installed even though 1.0.1 meets the dependencies, is there something I am missing?
It turns out an updated version of one of the updated sub-package's sub-package (a sub-sub-package if you will) dependencies did not fit with some of my other packages.
Related
In my pyproject.toml I have some dev dependencies configured as follows:
[tool.poetry.group.dev.dependencies]
mypy = "^0.971"
A simple poetry show -l shows that I indeed have mypy installed with version 0.971. Currently, the latest version available is v0.991.
What's the correct syntax to have all my dependencies - including dev dependencies - being updated.
poetry update --with=dev is not going to update mypy to the latest version.
poetry update updates dependencies within the version range given in the pyproject.toml.
^0.971 translates to >=0.971,<0.972 (See: https://python-poetry.org/docs/dependency-specification/#caret-requirements). This is why poetry update will not update mypy to 0.991.
To get the latest version of a dependency you have to use poetry add <dep>#latest. In your case poetry add -G dev mypy#latest.
At the moment there is no Poetry command to bump all dependencies to its latest version outside of the given version ranges. But there is a feature request for it: https://github.com/python-poetry/poetry/issues/461
In my go.mod, I have:
...
require (
...
sigs.k8s.io/controller-runtime v0.2.0-alpha.0
)
and for some reason, when I save my files, my go.sum gets updated to include:
sigs.k8s.io/controller-runtime v0.2.0-alpha.0 h1:WM6lus3SNU4SsMlDYvjJ5fyLsG9nW3ffb/4/FpE2ZGrtnc=
sigs.k8s.io/controller-runtime v0.2.0-alpha.0/go.mod h1:HFAsYoOh6XMV+jKF1rsUjFwrknPbowfyHEHH5fRdJMf2jMX8=
sigs.k8s.io/controller-runtime v0.6.3 h1:SBbr+inLPEKhrf87vlJtrvDcwIpm+uhDvp63Bl72xYJtoOE=
sigs.k8s.io/controller-runtime v0.6.3/go.mod h1:WlZNXcMs40++oyaQt4B7Cs2lEE5JYRs8vJUznj4aRP4N4JpdAY=
The first 2, I understand why they are there. However, why does the latest version (0.6.3) of the package also appear all of a sudden?
When I run, go mod tidy, I get errors suggesting that 2 files in my codebase point to packages in the latest version (0.6.3) of this package. What can I do to strictly use the 0.2.2 version in go modules + in my codebase?
go mod tidy:
<filename here> imports
sigs.k8s.io/controller-runtime/pkg/webhook/admission/builder: module sigs.k8s.io/controller-runtime#latest found (v0.6.3), but does not contain package sigs.k8s.io/controller-runtime/pkg/webhook/admission/builder
v0.2.0-alpha.0 appears to already be the version that your module is using, so you don't need to do anything to “force” it. (The version of the go command that you are using may be erroneously saving the go.sum file before it errors out. If that reproduces with the latest version — currently go1.16rc1 — please file an issue, with steps to reproduce it, at https://golang.org/issue/new .)
The error message is telling you that the go command is looking for a missing package (sigs.k8s.io/controller-runtime/pkg/webhook/admission/builder).
It is checking in the latest version of the modules that may contain that package, but the latest version (which is v0.6.3, whereas your module requires v0.2.0-alpha.0) still does not contain that package.
So the go command is telling you, essentially: “I am missing the package sigs.k8s.io/controller-runtime/pkg/webhook/admission/builder, and I cannot fix it by upgrading because v0.6.3 does not contain that package either”.
I 'd like to pin the version of one package, so whenever I run
go get -u ./...
..this package would stay unchanged (but the rest refreshed normally).
Use go modules. It was specifically designed to handle precise version control.
In your package's go.mod you can pin any dependencies to a fixed version e.g.
module example.com/hello
go 1.12
require (
golang.org/x/text v0.3.0 // indirect
rsc.io/quote v1.5.2
rsc.io/quote/v3 v3.0.0
rsc.io/sampler v1.3.1 // indirect
)
You can update individual package versions e.g.:
go get rsc.io/quote/v3#master
Will pull the latest commit version (beyond even any semver tagged version).
You can also hand edit go.mod for extra precision.
P.S. you need go version 1.11 or later for go modules. go 1.13 has modules turned on by default. Earlier versions you have to explicitly enable it via the env var GO111MODULE=ON.
I pushed my package medyes/ebay-api on github.
When I tried to download it on another project with composer I have an error:
Command composer:
composer require medyes/ebay-api:dev-master
The error:
[InvalidArgumentException]
Could not find package medyes/ebay-api at any version for your
minimum-stability (dev). Check the package spelling or your minimum
-stability
this is the composer.json of medyes/ebay-api package
composer.json
Avoid using branches - especially when the project you are about to include offers tagged versions.
composer require medyes/ebay-api:~0.1
This will update this package until version 1.0 comes out (which would not be installed, because that major release number change it is considered incompatible according to semantic versioning) every time a newer, installable version exists and you run composer update.
I have two OSGi bundle with same name. But there versions are different. Suppose one bundle has version 1.0 and another one is 2.0 . as 2.0 is higher version so its priroty will be first. But I want to use a piece of code from bundle 1.0 also. How can I achieve this ??
The bundle version is not reall important when OSGi selects where to import a package from. The only limitation there is that you can not install two bundles with the same symbolic name and version.
What you need is to version the packages the bundles export. Each of the packages can be exported with a different version if you want. In the client bundle you can then import each needed package with an allowed version range.
So bundle 1.0 can export package a in version 1.0 and package b in version 1.1.
Bundle 2.0 can export package a in version 2.0 and package b in version 1.2.
In the client bundle you could then
import package a with a version range of [1.0,2.0) -> would resolve to package a from bundle 2.0
import package b with a version range of [1.1,1.2) -> would resolve to package b from bundle 1.0
You can only do this on the package level though. So you can not access classes that are in the same package from different bundles - at least not without fiddling with classloader... which you should avoid.