search

mediocregopher / goat

A simple, yaml-based go dependency manager
Apache License 2.0
68 stars 11 forks source link

Install dependencies w/o .go.yaml file #15

Closed trans closed 10 years ago

trans commented 10 years ago

Even if a dependency doesn't have a .go.yaml file, I think the dependency should still be installed. For now that means sub-dependencies won't get installed, but if eventually goat can auto-generate a .go.yaml file per issue #14, then it could do that to make up for a project's lack of one.

mediocregopher commented 10 years ago

Is that not currently the case? It outputs a message that the dependency doesn't have a .go.yaml file, but that's only to say that no sub-dependencies will be installed. The dependency itself is still there.

trans commented 10 years ago

Ah, I see what happened. They are being installed in .deps not .goat/deps. I didn't realize that had changed. Ok.

mediocregopher commented 10 years ago

oh crap I forgot we were gonna do .goat/deps. That's an easy fix though.

trans commented 10 years ago

Well .deps is fine too.

This just gave me a thought though with regard to our previous conversation on this topic and the use of .go.yaml. Might we use a .go directory? i.e.

  .go/deps
  .go/deps.yml

Which then leads me me think only dependencies would be in .go/deps.yml and another file, maybe something like info.yaml, that would have the other information, i.e. path. So...

  .go/deps
  .go/deps.yml
  .go/info.yml

?

mediocregopher commented 10 years ago

I'd rather keep the part the user has to actually interact with all in one place and right in front of them, not in a sub-directory. I want to keep this as straightforward as possible for someone to use.

trans commented 10 years ago

Ok. Maybe .go/deps is still a good way to go? Or maybe just .deps/ is better then?

mediocregopher commented 10 years ago

The stuff goat generates (the dependencies) is going to be in .goat/deps, once I fix that. I don't care if the goat generated stuff is organized in a tree, but the .go.yaml file needs to be the only thing the user actually touches, and it needs to be in the root of their project where they can easily find it. I don't want them to have to root around inside the .goat directory, which has a bunch of scary looking stuff.

trans commented 10 years ago

Right I got that. I only meant maybe .goat -> .go. Still keep .go.yaml.

mediocregopher commented 10 years ago

i'd rather it stay .goat. The .go.yaml file may be used by other utilities, but the stuff goat generates I want to be able to have flexibility on and not have it become something else that must be backwards compatible.