What is the difference between
babel-core and #babel/core ?
Are they the same thing but different versions? If not so, when do you use one and when do you use the other?
Thank you.
Since Babel 7 the Babel team switched to scoped packages, so you now have to use #babel/core instead of babel-core.
But in essence, #babel/core is just a newer version of babel-core.
This is done to make a better distinction which packages are official and which are third-party.
Related
Does anybody have any experience with defining the python version of boost-python when installing from vcpkg?
I'm trying to use OpenVDB's python interface, and while I can get it working with the default python39 boost library, I'm not able to figure out how to define which boost-python version to install with vcpkg, and/or don't know how to define the correct parameters for the cmake command line to specify a python version at that point.
The default library that boost uses is 3.9, but as I'm typically in Anaconda, and 3.9 is not a standard download, I wanted to hold the boost library to be 3.8 instead.
I've commented in the github issues for openvdb, https://github.com/AcademySoftwareFoundation/openvdb/issues/946
but as this is not an issue with that project, and more of a dependencies thing, I thought I'd ask here in case you seen this on your travels :)
Thanks in advance for your time.
Neil
I have a nuspec file that builds a nuget-package. I would like to control the dependencies, where I allow a range of versions, but what to always install a spesific version.
Basically this (not valid syntax):
<dependency id="Microsoft.CrmSdk.CoreAssemblies" version="8.2.0.2" allowedVersions="6.0.0" />
I want the nuget to dependency to accept 6 or higer (up to 9), but always want it to install 8.2.0.2 as default.
If I had version="6.0.0", it would always install the 6 version?
Any tips?
It is possible to specify an accepted version range in a nuspec-file with a version-range syntax. Accepting every version with a major version between 6 and (including) 9 would be specified by [6.0.0, 10.0.0).
What I understand from your question is that you want to specify an accepted version range but you want to force a certain version to be installed. There is no way I know of to achieve this but I also don't see the requirement for it: By specifying an accepted version range, the nuspec-file specifies to which versions of the dependency packages this package is compatible with. Hence, all accepted versions should work.
Forcing a certain version to be installed contradicts this compatibility statement in my opinion. This sounds as if you want to achieve a different goal: To verify that a consistent version of a NuGet package is installed in an application. This, however, should be solved on the consuming side, i.e. the solution that installs the NuGet packages. Assume the nuspec-file defines a package A that accepts all versions [6.0.0, 10.0.0) from Microsoft.CrmSdk.CoreAssemblies, but the consuming solution should always use version 8.2.0.2. Then this version 8.2.0.2 should be installed there first and afterwards the current version of package A can be installed, finding its dependency to Microsoft.CrmSdk.CoreAssemblies already resolved.
To achieve a consistent consuming solution, we implement checks on the CI server that verify that every package is referenced in all projects in exactly one version. By this we get a consistent product while keeping the actual NuGet packages flexible to be used with a different version of dependency packages in other products.
I'm quite experienced with ReactJS and now I'm trying to learn ReasonML. But one thing that I've been struggling to understand, is how to import npm packages with React/Reason.
The instructions on the website are kinda unclear to me (https://reasonml.github.io/guide/javascript/interop/).
So, if I have a React/Reason project and want to use a npm package, how do I do it? How do I import it, using Reason lang?
First off, thanks for the feedback! I'll make sure to get this improved.
Now, to be able to use a javascript library published on npm, you'll need to either find or make some bindings for it, as a bridge between Reason/BuckleScript and JavaScript. Ideally, the bindings you need have already been written (or generated) and published to npm, but in case it hasn't you'll have to write them yourself.
Most readily available bindings are listed in redex, the package index, and will include instructions on how to use it. But if they don't, all you need to do is run npm install --save <package-name>, as usual, then add the package name to the bs-dependencies array in bsconfig.json (see also the BuckleScript manual). Make sure to run bsb -make-world to get the new dependency built, then you should be able to use the modules exported by the bindings directly.
If there are no bindings, and you want to make your own, all you need to do is add the javascript package as normal using npm install --save <pacakge-name>, then just start writing externals. How to do so is described in the BuckleScript manual. You may also find my FFI cheatsheet useful.
Lastly, you're welcome to join us on our Discord where there's lots of friendly people eager to help!
I'm creating an RPM and I need to check that a version of Java 8 is installed on the machine.
The problem is that Oracle provides version-tied RPMs with names like jdk1.8.0_45 and Redhat provides RPMs with names like java-oracle-8. I don't really care which one is installed, as long as one of them is installed, so how can I define OR condition logic on a Java 8? (Note this is for a RHEL5 or RHEL6 target, so new fangled features can't be used)
As far as I'm aware RPM has no such functionality. You cannot declare a requirement like this.
That being said what RPM does have, and which is used as a rough equivalent to this, is the concept of "Provides".
Any package can Provide: some_capability and then other packages can Require: some_capability the same way they can Require: <some_package>.
You can also Require: /some/file/path if absolutely necessary (though avoid this whenever possible).
So, you need to compare the provided capabilities of the RPMs you care about and look for any common capability that you can depend on instead. Hopefully there's something in common there you can use. If there isn't then you are left with no choice other than to drop the requirement in your RPM and hope they have it and detect it at runtime (with a startup script perhaps).
(Technically you could also do a check during %pre and exit with a failure if you can't find java somewhere but I strongly recommend not doing that.)
FYI - boolean logic in dependecy is called "Rich dependency" and is currently being introduce into RPM and will probably land in Fedora 24. See http://lists.rpm.org/pipermail/rpm-maint/2014-February/003666.html
After testing my Catalyst application and deciding to deploy it I would like to package it up so I can easily pull it in on the staging and live servers, manage dependencies and easily roll-back via the flexibility of package versioning. As my production OS is Ubuntu I figured packaging it as a deb package would make most sense.
I am predicting I will have to create a second package of all my perl module dependencies as many are not provided by my distribution, or package them independently - though that may be a lot of work.
Does anyone have any experience of doing this - or a sane, similar alternative?
To build your own Debian packages out of CPAN packages:
Install Debian helper scripts
sudo apt-get install dh-make-perl
Download MODULE from CPAN and build Debian package
cpan2deb MODULE
dh-make-perl is actually the right tool to put CPAN modules into Debian packages. Together with apt-file it can even prepare proper dependencies for you.
About being able to "easily roll-back" though requires special attention to versioning or workflows. There are several approaches that might get your job done here:
If you can force-downgrade packages you have won already most of the time unless you have very specific maintainer scripts that do jobs on package upgrades - then you will have to make them able to handle the downgrade, too
If you have to go the regular upgrade-path, using approaches like using "< newversion>+rollback< oldversion>" or similar might be something to consider.
Dependency-packages are always a good idea for deployments to make sure no required package actually is missing. Also, you might want to invest some time in management frameworks like puppet, they might come handy here, too.