Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adhoc git dependencies over *http* not working #323

Open
nikhedonia opened this issue Feb 26, 2019 · 9 comments
Open

adhoc git dependencies over *http* not working #323

nikhedonia opened this issue Feb 26, 2019 · 9 comments

Comments

@nikhedonia
Copy link
Collaborator

works fine via ssh

@DeanHnter
Copy link

Recently tried this and struggling to get any dependencies not on the default github.com, bitbucket or gitlab extension to work. It doesent help that there doesent seem to be many examples online about pulling dependencies from hosted git and HTTP so the syntax is somewhat unclear so may be my fault but : buckaroo add github.com/buckaroo-pm/boost-thread@branch=master this doesent work if i change the url to a self hosted git repo, infact I get various syntax errors by changing from github.com to my own hosted url buckaroo add myservices.com/myrepo/examplepackage@branch=master the error i get is : Expecting: end of input, whitespace, '--verbose' or '@' in reference to the part "myrepo/examplepackage"

@nikhedonia
Copy link
Collaborator Author

nikhedonia commented Mar 2, 2019

Yes at the moment it is not documented and not available via the cli.
You can explicitly define an adhoc dependency by editing the manifest:

[[location]]
name = "owner/project"
git = "git@url/to/git/repo.git"

[[dependency]]
package = "owner/project"
version = "branch=master"

Direct git dependencies are slower to resolve as we need to fetch commits before we can read the manifest. Github/Gitlab/Bitbucket have seperate apis to fetch files for a given commit.

@njlr
Copy link
Collaborator

njlr commented Mar 2, 2019

Issue for supporting this in the CLI: #328

@njlr
Copy link
Collaborator

njlr commented Mar 2, 2019

Would add the the reason we don't use the Git URL as the name is:

  1. This is not possible for HTTP, since we have n URLs per version
  2. It makes it clear how to specify alternative URLs (e.g. for Git SSH)
  3. It enables the URL to be changed without editing all of the downstream manifests
  4. It provides something more intentful (is that a word?!) to use in build scripts

However, this is up for discussion! 🙂

@DeanHnter
Copy link

This is actually very understandable and helpful, thanks for the responses :) @njlr @nikhedonia , the only concern id raise is that maybe it should be in the documentation outlining usage as its a fairly common use-case to have repo's not on github etc particularly for private companies and may be a decisive factor in choosing a package manager for a cpp project for some people. If you think its worthwhile, I also I dont mind doing it but seems important that if its already available even not via the CLI its worth including a section on just to prevent people moving to other package manager when they otherwise wouldnt. Thanks again for the helpful responses 👍

@njlr
Copy link
Collaborator

njlr commented Mar 4, 2019

@DeanHnter
Copy link

DeanHnter commented Mar 9, 2019

Thanks for the update, Much clearer now! I tried to follow those steps but when I add [[location]] in my buckaroo.toml I get parsing errors:

System.Exception: Could not read project manifest. Are you sure you are in the right directory? ---> System.Exception: Error parsing manifest: Unexpected type table at Buckaroo.Tasks.readManifest@70-2.Invoke(String _arg1) in /home/travis/build/LoopPerfect/buckaroo/buckaroo/Tasks.fs:line 74 at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck[a,b](AsyncActivation1 ctxt, FSharpFunc2 userCode, b result1) at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc2 firstAction)
--- End of inner exception stack trace ---
at Buckaroo.Tasks.catchHandler@1-4(Exception _arg2) in /home/travis/build/LoopPerfect/buckaroo/buckaroo/Tasks.fs:line 77
at Buckaroo.Tasks.readManifest@68-7.Invoke(Exception edi) in /home/travis/build/LoopPerfect/buckaroo/buckaroo/Tasks.fs:line 68
at Microsoft.FSharp.Control.AsyncPrimitives.CallFilterThenInvoke[T](AsyncActivation1 ctxt, FSharpFunc2 catchFilter, ExceptionDispatchInfo edi)
at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc2 firstAction)

Is this regular or am I doing something incorrect?

The buckaroo.toml looks like this:

[[location]]
name = "d2191/Catch"
git = "git@localhost:d2191/Catch.git"

[[dependency]]
package = "d2191/Catch"
version = "branch=master"

@njlr
Copy link
Collaborator

njlr commented Mar 9, 2019

Should be:

[[location]]
package = "d2191/Catch" # <---------------- Here
git = "git@localhost:d2191/Catch.git"

[[dependency]]
package = "d2191/Catch"
version = "branch=master"

My mistake for copy-pasting without checking.

@ko1N
Copy link

ko1N commented May 30, 2019

I get this issue when trying to pull in repos from a private git that uses a custom port:

[git] info Fetching refs from ssh://git@gitlab.some.host:1234/buckaroo/protobuf.git
[git] success Fetched 1 refs in 1.204
[solver] warning Unresolvable: protocolbuffers/protobuf@branch=master

Toml file looks like this:

[[location]]
package = "protocolbuffers/protobuf"
git = "ssh://git@gitlab.some.host:1234/buckaroo/protobuf.git"

[[dependency]]
package = "protocolbuffers/protobuf"
version = "branch=master"

(Also as a side node, I had to fork protobuf because protoc from the supplied repos was crashing unless i changed compilation to cpp11 as protobuf does it in cmake)

Edit:
Nevermind, its not because of the gitlab repo its because i have more than 1 ad-hoc dependency in my project it seems. Depending on how I order them in the toml file one of the dependencies cannot be resolved (which changes if i shuffle dependencies around in the toml file)... quite interesting...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants