I want to install package A which has a dependency of Package B, and Package B has 2 providers, When I install package A, can we specify in the spec file which provider to be used to download package B when it’s being installed as a dependency
When you say "provider" - do you mean "repository?" If so, no.
A workaround would be to repackage the RPM with a different %dist tag, and then by explicitly calling that out, you would force it to use the version from your local repo. But that would be a rabbit hole that's probably not worth running down.
Related
FYI, I'm quite new to Python and it's packaging and dependency tools seem confusing.
I am going to be writing series of Python packages that support Dags running in Apache Airflow. As these packages share some common functionality I want to extract the commonalities out into separate supporting modules. In turn, these supporting modules will rely on at least two other supporting modules. All of the modules/packages in question will be published as source distributions on an internal repository.
Is there a way for me to install the main packages such that all of the direct and indirect dependencies are installed from the private repo?
I have made use of install_requires in setup.py to install modules available via Pypi and it seems like I could do something like this to achieve my goals, however this seems like it could get messy when I need to update say the version of the indirect dependencies. Is there a better way that I can handle this? Would adding the dependencies to requirements.txt with an --extra-index argument be a valid approach?
The hierarchy of dependencies can be represented loosely as:
MainPackage
-> SupportingPackage
-> CommonUtilites
It is possible to use a git repository as a Python package source.
Just add git+{REPO_LINK}#{TAG_OR_SHA1} in requirements.txt and just pip install -r requirements.txt.
See How to add git source in requirements.txt.
Have a basic doubt about puppet package resource.If I have a package resource declared in the the manifest file for eg:to install apache using apt-get.
1.During the first run of puppet agent,apache will get installed.
2.If I run the agent(using the existing code for package resource) again after ubuntu repo is refreshed with latest version of apache.
Will puppet update/refresh the apache in agent server?
The Package's ensure attribute determines the state.
What state the package should be in. On packaging systems that can retrieve new packages on their own, you can choose which package to retrieve by specifying a version number or latest as the ensure value. On packaging systems that manage configuration files separately from “normal” system files, you can uninstall config files by specifying purged as the ensure value. This defaults to installed.
Version numbers must match the full version to install, including release if the provider uses a release moniker. Ranges or semver patterns are not accepted except for the gem package provider. For example, to install the bash package from the rpm bash-4.1.2-29.el6.x86_64.rpm, use the string '4.1.2-29.el6'.
Valid values are present (also called installed), absent, purged, held, latest. Values can match /./.
Source: https://puppet.com/docs/puppet/5.3/types/package.html#package-attribute-ensure
If I have versions 1.1 and 1.2 of package foo installed on my system, and bar.js requires package foo, is there a way to invoke node bar.js so that node uses version 1.1 of foo?
NPM packages that are local to the project stay in node_modules and don't update unless you explicitly update them yourself. You can use NPM's semantic versioning to manage the granularity of your dependencies on a per-project basis. Here's a semver cheat sheet: https://semver.npmjs.com/
With that in mind, where this breaks down is if you're installing modules globally (which you should not be doing unless the package owner tells you to, e.g. Grunt or Angular-CLI). If you are using global modules and you don't need to be, you should fix that ;)
If you find that semantic versioning is causing conflicts for dependencies within your project (e.g. foo requires bar 1.0 and faa requires bar 1.1) OR you are concerned about the risk of breaking dependency changes, take a look at Yarn.
I'm attempting to start a new project using the Snap web framework. I used snap init to get my basic skeleton working. I also put http://www.stackage.org/lts/cabal.config next to my .cabal file. I didn't uncomment the line to use Stackage exclusively. So I tried to build and it failed and couldn't find the version of lens required by my .cabal file. The cabal.config file from Stackage specifies a version of lens that is not the same as the one in my .cabal file. So I deleted every constraint from my package list and did the usual cabal install --only-dep -j8 --enable-test and it worked!
However, I have always been told that package versions should be constrained. So when working with Stackage is it okay to leave package versions unconstrained? Should I downgrade my packages to the ones available in Stackage instead?
As far as I understand a cabal.config file specifies a set of dependencies with the specific versions that satisfy dependencies, so how does Stackage work? Is it just a subset of packages from Hackage that are proven to be compatible? Do they host their own packages or rely on Hackage for downloads?
Thanks in advance :)
Both options are available. The default option is what you did, and still goes to hackage to get the packages. You just added a filter to your cabal that prevents you from using any version of a package included in Stackage that was not tested to work together with all of the other packages.
The other option is to simply point your cabal repo to a Stackage url, and then you will download packages directly from the Stackage server. That server will only serve packages that are known to work together, so there is no need for additional constraints in your cabal file. I actually prefer this way of working.
In both cases, if you have additional constraints in your cabal file that are incompatible with the Stackage restrictions, your build will fail. If you use the first option, you will get dependency conflicts. When using the second option, the Stackage server will simply report that it does not have that specific package/version.
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.