search

owenthereal / nut

Vendor Go dependencies
https://github.com/jingweno/nut
MIT License
232 stars 11 forks source link

Why only for binaries?, godep mentioned limitation and party #2

Closed ifraixedes closed 9 years ago

ifraixedes commented 9 years ago

Hi,

Thanks for this awesome hack. I would like to ask you a couple of question that I'm in doubt, sorry I'm not much experienced in Go and maybe they are silly questions, however I've taken a look before asking and I couldn't get the answers, but they are very valuable for me as I could learn from your experience for a professional use.

nut is specifically designed to manage dependencies for a binary program. If you are making a library, please follow the standard Go way.

After this comment, I'm wondering why isn't it appropriated to develop a library?

However, godep doesn't allow updating any dependency with rewritten import paths

What do you mean? Isn't it possible to update the commit SHA in Godeps.json, then delete Godeps/_workspace directory and run godep save again?

Is Nut.toml the difference with mjibson/party?

Many thanks in advance.

owenthereal commented 9 years ago

I'm wondering why isn't it appropriated to develop a library?

Sorry for the confusion on the README. I didn't have enough time to explain everything at the 48 hours Gopher Gala :wink:. It's not impossible to support this feature in nut. However, my original goal was to solve the number one pain point when developing a binary problem like hub: locking vendored dependencies and easy update of locked vendored dependencies. Besides, I haven't thought through what would be the best way to accomplish vendoring a library without causing problems when this library is vendored in a binary program. For example, assuming both a library and a binary program vendor dependencies:

- a_library:
  - vendor
     - _nuts
       ...

- binary_program:
  - vendor
    - _nuts
      ...

When we run nut install in binary_program, do we copy all dependencies in a_library/vendor/_nuts to the binary_program? What if there're dependencies defined in binary_program conflicting with what are in a_library? However, I do really want to support vendoring dependencies for a library. It's just a matter of time to iron this out.

Isn't it possible to update the commit SHA in Godeps.json, then delete Godeps/_workspace directory and run godep save again?

I wasn't aware I could do that...But it looks very cucumber-some. This also comes with my another frustration: all the Go dependency manager tools out there are not as straightforward and not as familiar. I really wish it could be as simple as nut update FOO and the job is done. nut is trying to fill this gap.

Hope that helps.

ifraixedes commented 9 years ago

Sorry for the confusion on the README. I didn't have enough time to explain everything at the 48 hours Gopher Gala :wink:

Sure, it is totally understandable.

Thanks for your reply, it is really helpful to know about your experience.

I wasn't aware I could do that...But it looks very cucumber-some. This also comes with my another frustration: all the Go dependency manager tools out there are not as straightforward and not as familiar. I really wish it could be as simple as nut update FOO and the job is done. nut is trying to fill this gap.

I know that you mean, automatisation is keen but it must work, at least if it could work for binaries with no pain, then it's a good progress.

Many thanks for your time.