3 ms·

It says it is inspired by Bundler but in what ways? I am curious as I didn't use much of neither bundler nor goop but I have heard the constraints resolution la

It says it is inspired by Bundler but in what ways? I am curious as I didn't use much of neither bundler nor goop but I have heard the constraints resolution lays in the heart of bundler.

raingrove 12y ago
You are right. Unfortunately, constraints resolution isn't something that can be implemented in a practical manner until there is a standard versioning scheme (there isn't much you can do with git hashes) and a standard dependency manifest file that every go project adopts. Goop has `Goopfile.lock` and `goop exec`, inspired by Bundler's `Gemfile.lock` and `bundle exec`.
- grey-area 12y ago
  until there is a standard versioning scheme (there isn't much you can do with git hashes) Couldn't you use tags for versioning? Often people use tag v1.1.1 etc?
  - cstrahan 12y ago
    See: "and a standard dependency manifest file that every go project adopts" You need some way to create a complete dependency graph for a given project. If your project has a list of its immediate dependencies, but those dependencies in turn require specific versions of other packages, how do know what those versions are? You need some consistent way of getting this metadata. There are a couple solutions, but a few that come to mind: each project stores their deps metadata in a consistent location in their repo, or there's some central package repo (a la RubyGems) where such metadata can be queried. For any solution to work, all of your dependencies (both direct and indirect) need to opt in to the same metadata scheme, or the system falls apart. Unfortunately, there isn't any consensus in the Go community on how to fix this. This is what the parent meant by "there isn't much you can do with git hashes."
munificent 12y ago
From the looks of it, it just has a lockfile. None of the version resolution that makes bundler interesting.

It says it is inspired by Bundler but in what ways? I am curious as I didn't use much of neither bundler nor goop but I have heard the constraints resolution lays in the heart of bundler.

raingrove 12y ago

You are right. Unfortunately, constraints resolution isn't something that can be implemented in a practical manner until there is a standard versioning scheme (there isn't much you can do with git hashes) and a standard dependency manifest file that every go project adopts. Goop has `Goopfile.lock` and `goop exec`, inspired by Bundler's `Gemfile.lock` and `bundle exec`.

grey-area 12y ago
until there is a standard versioning scheme (there isn't much you can do with git hashes) Couldn't you use tags for versioning? Often people use tag v1.1.1 etc?
- cstrahan 12y ago
  See: "and a standard dependency manifest file that every go project adopts" You need some way to create a complete dependency graph for a given project. If your project has a list of its immediate dependencies, but those dependencies in turn require specific versions of other packages, how do know what those versions are? You need some consistent way of getting this metadata. There are a couple solutions, but a few that come to mind: each project stores their deps metadata in a consistent location in their repo, or there's some central package repo (a la RubyGems) where such metadata can be queried. For any solution to work, all of your dependencies (both direct and indirect) need to opt in to the same metadata scheme, or the system falls apart. Unfortunately, there isn't any consensus in the Go community on how to fix this. This is what the parent meant by "there isn't much you can do with git hashes."

munificent 12y ago

From the looks of it, it just has a lockfile. None of the version resolution that makes bundler interesting.