Re: [go-nuts] Re: Keep Vendor folder on library Repository is Bad or Good practice.

2018-08-13 Thread Dan Kortschak
It is still there because someone if (hopefully) benificently name
squatting there with the same package. It went away and broke things.
The person who owns jteeuwen is not Jim (the original owner), and has
put back the go-bindata repo to avoid a breakage. It could be far
worse.

On Mon, 2018-08-13 at 11:17 -0400, Tong Sun wrote:
> I have no idea what's going on there or the history, but I see
> https://github.com/jteeuwen/go-bindata is still there, despite that
> "this
> repository is not maintained".

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Keep Vendor folder on library Repository is Bad or Good practice.

2018-08-13 Thread Tong Sun
I have no idea what's going on there or the history, but I see
https://github.com/jteeuwen/go-bindata is still there, despite that "this
repository is not maintained".

On Thu, Aug 9, 2018 at 8:58 AM peterGo  wrote:

> Tong Sun
>
> "I've never seen [the Author delete the library]  happen before."
>
> It happened recently. Take a look at jteeuwen/go-bindata: Hard fork of
> jteeuwen/go-bindata because it disappeared,
>
> Peter
>
> On Wednesday, August 8, 2018 at 10:01:32 AM UTC-4, Tong Sun wrote:
>>
>> I've never seen that happen before, but in case it does, only new
>> environments will fail, i.e., those has been building fine will still be
>> building fine. I.e. it's quite easy to correct.
>>
>> So I personally think that it is really a high price to pay for something
>> that may *never* happen.
>> Of course, not everyone agree with me, as I've seen someone even worries
>> that go yaml (gopkg.in/yaml.v2) will go away someday, and insists
>> vendering it.
>>
>>
>>
>> On Wednesday, August 1, 2018 at 9:50:13 AM UTC-4, nafis wrote:
>>>
>>> How about the Author delete the library.
>>>
>>> On Tuesday, July 31, 2018 at 5:49:36 AM UTC+6, Eric Johnson wrote:

 Long term, I suspect you're better off without the vendoring.

 Specifically, I suggest looking into automating your libraries tests
 with the earliest possible versions of supported dependencies, and the
 latest versions of dependencies.

 With a tool like vgo, it should be possible to have two versions of
 your lock file that your build / test cycle can switch between. If a
 project adds backwards compatible changes, they you can test across major
 versions as well.

 Eric

 On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote:
>
> Suppose I'm making a library and it does reference some other library
> not part of the standard library. I want to vendor those so that my 
> library
> doesn't fail if the other 3rd party developer deletes their library or
> major changes of their library(I know this sound like stupid design). And 
> I
> want to push the vendor folder on my library repo. My question: Is
> this the bad idea keep a vendor folder on the library repo.
>
> Thank you for your time.
>
 --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/yASFt3PY_yg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.