Please correct me, if I were wrong! I assume that:
a)REQUIRES, Project.toml and Manifest.toml, Registries are used in dependency resolution in julia.
b)Project.toml and Manifest.toml can exist at both master level(ie. at user level or host level) and at project level.
c) REQUIRES and Project.toml and Manifest.toml can exist simultaneously.
Please help me in understanding the functionalities of REQUIRES, Project.toml&Manifest.toml and Registries and how the dependencies are resolved when more than one mechanism (for example, case 1: REQUIRES and Project.toml and Manifest.toml exist in a project) exists together.
On the old package registration system METADATA (Pkg 2 - up to Julia 0.6), dependencies were resolved using REQUIRES. On the new registration system (julia 0.7 upwards) dependencies are resolved using Project.toml and Manifest.toml. So your Julia version determines which method is used.
The Manifest contains a complete record of the versions of all dependencies and transitive dependencies needed for a given environment. You can read more here: https://julialang.github.io/Pkg.jl/v1/managing-packages/
Related
Are the locations intentional? I have an issue where sbt always seems to fetch dependency externally rather than from local. When external resolvers are removed, the dependency cannot be resolved because the path .ivy2/local does not exist.
In order to customize a third-party Meteor package, I copied the package folder from /Users/<name>/.meteor/packages/accounts-ui-unstyled/.1.1.8.cfkrwq++os+web.browser+web.cordova/ and pasted it into the packages folder at the root of my app as accounts-ui-unstyled/.
Now when the app compiles, I get this error:
Errors prevented startup:
While selecting package versions:
error: No version of accounts-ui-unstyled satisfies all constraints: #=0.0.0, #=1.1.8
Constraints on package "accounts-ui-unstyled":
* accounts-ui-unstyled#=0.0.0 <- top level
* accounts-ui-unstyled#=1.1.8 <- top level
* accounts-ui-unstyled#1.1.8 <- accounts-ui 1.1.6
Your application has errors. Waiting for file change.
Where are these constraints being declared, and what do I need to change to get the accounts-ui-unstyled/ folder in the packages folder to be correctly identified?
Normally you would like to create a local copy of a package by cloning its repository from GitHub (provided the source is available), and not from your local file system (which holds pre-built versions of the packages).
Sometimes (as it is the case with the core Meteor packages), they are "hidden" in sub-directories of the repository.
A neat trick is to use SVN in order to quickly get a snapshot of that sub-directory:
$ mkdir packages && cd packages
$ svn export https://github.com/meteor/meteor/trunk/packages/accounts-ui-unstyled
If you want to pull from a specific branch, use
$ svn export https://github.com/meteor/meteor/branches/<branch_name>/packages/<package-name>
The constraints will be specified in the package.js file, as expected.
Note: MDG are planning to move the core packages into their own repository/repositories, so those instructions may not be valid for the core packages in the future.
I downloaded a Meteor Starter project called MeteorAdmin.
In the root of its directory tree, you find a packages directory that contains few packages (boostrap, comments, few others) and also, in the .meteor directory there's a file called packages that defines the dependencies of this project.
What is the difference between them? What I found interesting is that .meteor/packages contains bootstrap as well. In theory shouldn't that be enough so that bootstrap would get downloaded to the project?
The meteor packages file simply lists all of the apps dependencies as well as the load order of each (top to bottom). You can edit this file if you know what you are doing, but it's probably better to leave it alone until you are more familiar with Meteor.
The way you add packages is by typing meteor add <package-name> in your terminal and then it will be added to your project. Additionally, the name of the package will be added to the bottom of your packages file.
A meteor app can have local packages that are defined in the packages folder of the root directory. This project likely is implementing it's own bootstrap package and then added it with the meteor command I listed above. Once a local package is added to your project with the meteor add command it's package name will appear in the packages file just like packages from Atmosphere. I hope that answers your question... Let me know if you were looking for something more specific.
I installed couple of packages for 'Project A' (e.g bootstrap) assuming that it will be available for all subsequent projects. But when a new meteor project 'Project B' was created, meteor list showed only default packages. So my assumption that meteor packages are like ruby gems available globally is incorrect. As I work offline every now and then, Is there a way I can manually copy/re-use installed packages?
Yes they are similar to gems. Packages are installed in ~/.meteor/packages, in precompiled form. They can be installed globally this way.
When you add a package to your project it will essentially copy the package from there into your build-cache directory hidden in the .meteor directory of your project.
To install a package locally where you can easily re-use it you would have to clone the github repository of the package and place the output in the /packages directory of your Meteor app.
For example for bootstrap, twbs:bootstrap you would clone this reposistory: https://github.com/twbs/bootstrap, into a directory like /packages/twbs:bootstrap (name doesn't matter if its defined in the package.js file on the repository.
In general you can easily re-use a package without the hassle of adding it in manually like so. It's better to use the global packages which are kept up to date.
The trouble comes with being offline. If you use a local package its nearly guaranteed to always work. Whereas the global ones can give a bit of trouble once in a while when you try to add a package in as meteor tries to check the package is up to date, especially where npm packages are involved with the package.
To keep it short if you added a package in using meteor add twbs:bootstrap you should most likely be able to add it to another project using the same command. Only if you keep your packages & meteor up to date.
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?