Closed Vorlent closed 6 years ago
@Vorlent can you clarify "has no concept of versions"?
do you mean, that dependencies always use HEAD? if yes, then that isn't the case. However, there are certainly improvements that can be made. It doesn't for example, do ranges. You can use a specific git tag/commit. For example...
https://github.com/WallarooLabs/wallaroo/blob/master/machida/bundle.json#L8
Okay I didn't know about the ability to specify versions inside tags.
Handling the minor and patch versions with tags this way is perfectly okay as long as the library does not have any breaking changes. But when backwards compatiblity is broken you need to be able to use two major versions of the same library in one program. Does pony-stable handle this in any way?
Let's take the pony-inspect library. Suddenly one day version 2.0.0 of pony-inspect is released. How do I use it via pony-stable?
Does pony-stable offer a solution beyond just putting the major version into the package name like this?
use "inspect"
use "inspect2"
you would change the version in your bundle.json to match the API you are using in your code:
{
"deps": [
{ "type": "github",
"repo": "jemc/pony-inspect",
"tag": "2.0.0"
}
]
}
you would version your bundle.json along with your changes to upgrade to whatever the API changes were for the new version of pony-inspect.
Ok. Thank you.
Right now pony-stable still has no concept of versions.
I'd like pony-stable to follow the model of Rust's Cargo but we can avoid version ranges for now.
A basic package manager needs to do implement these rough functions.
Define the dependencies inside a manifest.
Optional: If version ranges will be supported the package manager has to use constraint solving to generate the current dependency graph and save it in a lockfile. The lockfile has to be commited to the repository to ensure reproducible builds.
Fetch the dependencies and store them in this flat path structure:
(Let's avoid the recursive mess that NPM used to create before version 3.)
The last step is to give the compiler information about the location of the packages.
pony-stable already does 1., 3., 4. partially but it's still missing features such as version information.
What I'd like to see is the ability to specify the version in the manifest.
Without version ranges there are two primary version types in this scenario: static/pinned versions like
2.5.3
which could be denoted '=2.5.3' (in line with NPM and Cargo) moving versions likelatest
ormaster
that follow a branch which could be denoted as ':latest' (afaik no package manager uses colons as a prefix)Side Note: These symbols were chosen to leave room for version ranges if the need arises.
Step 1., 2., 3. can be implemented without modifying ponyc.
Step 4. is problematic when there is more than one version of a single package.
Here is an example dependency graph:
Right now there can only be one version of C. When B uses "C" the compiler looks for
.deps/C
rather than.deps/C/2.3.0
and D uses "C" it also chooses.deps/C
rather than.deps/C/1.4.0
.Ponyc has to be changed to support some sort of "package redirection" for specific packages.
Alternatively we could also use pony_packages and redirect from pony_packages/C to
.deps/C/2.3.0
on the filesystem layer via symlinks.I'm still not sure how to pass on the redirection information to the compiler.
Here are the two approaches I've figured out so far.
Package specific PONYPATHs via command line parameters. The path of the package is specified and the paths of the dependency packages. The command may become very large and hit limits of the CLI.
The alternative is that pony-stable generates a json file that contains this information and the compiler reads the redirect information from it.