Re: [go-nuts] Do you check in vendor packages?
Create a separate repo for vendor directory. Set it to "auto check-in" in main repo's git push hook. Done. Moreover, with submodule hash info included in main repo commits, the vendor repo can map better on checkouts. You could this skip submodules mapping if you don't mind rewinding manually when needed (which isn't often, is it?). Regards, Gurpartap Singh On Saturday, September 16, 2017 at 12:21:38 AM UTC+5:30, Will Faught wrote: > > Kevin, Henrik: > > Thanks for replying! > > Have you ever had to check in very large dependencies? Would you still do > it if just one dep added 30 MB to your 10 MB repo? What if the size of your > code is dwarfed by the size of your deps 10:1? I'm curious how far people > are willing to go to check in their deps—do they check in regardless of > size? Or is a hybrid approach the best, where you check in all but the very > large deps? > > I've been wondering whether the dep size cost is mostly a one-time, > up-front cost when you first check it in, and updates thereafter are > relatively very small, such that in the long run the size cost is maybe at > most 2x the initial size, which is basically a fixed, constant cost > compared to the ongoing size growth of your overall repo in the long run. > > On Thu, Sep 14, 2017 at 11:54 PM, Henrik Johansson <dahan...@gmail.com > > wrote: > >> I always check in. It is super nice to not have to download separately >> and have one transitive dep destroy everything when you need it the least. >> >> On Fri, 15 Sep 2017, 02:37 Kevin Malachowski <nifta...@gmail.com >> > wrote: >> >>> I generally vote for checking in, or at least ensuring that /something/ >>> has an in-house copy of all dependencies. The worst thing that can happen >>> is someone deleting their repository and having your project being super >>> broken. >>> >>> (See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) >>> >>> -- >>> 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...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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/EapE_L8TCdA/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@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.
Re: [go-nuts] Re: Go 2 suggestion - Types like "int?"
>>> }
>>>
>>> But every method that also returns an error, should not necessarily have
>>> an accompanied optional type, like `(int?, error)`. There's so much in Go
>>> that can be nil (or nil like zero-values), and isn't necessarily fit to be
>>> considered optional, like nil interfaces and pointers.
>>>
>>> We're also going to have to reconsider the phrase "errors are just
>>> values" if we want to pair non-optional types with error in the return
>>> types. Take the following suggestion (inspired from Swift):
>>>
>>> func getAge() (int, throws error) {
>>> var age int
>>> throw errors.New("ERR")
>>> // we're not returning anything and it compiles
>>> // i.e. throw *is* return but only for error
>>> }
>>>
>>> func main() {
>>> age := try getAge() // => panic("ERR")
>>> }
>>>
>>> func main() {
>>> // although getAge() returns a non-optional, it
>>> // gets is automatically wrapped in an optional
>>> // when using `try?`.
>>> //
>>> // basically we're trading error for nil value.
>>> age := try? getAge() // => Optional(nil)
>>> }
>>>
>>> func main() {
>>> // this is the graceful way to get non-optional result
>>> // and handle error, if any.
>>> try {
>>> age := getAge()
>>> } catch error {
>>> fmt.Println(err.Error()) // => ERR
>>> }
>>> }
>>>
>>> Therefore, if considered, optionals would be a *huge* undertaking to
>>> implement (and practice) in Go source, while also delivering the promise
>>> optionals bring.
>>>
>>> Let me know if you have a better syntax/suggestion than try catch blocks
>>> (for returning only an error; no zero-values for non-optionals).
>>>
>>> I think an ideal first step would be the community blessing and adopting
>>> en masse some Optional "generator". Second step would be to vouch for
>>> generics with this use case. And then implement an actual generic like
>>> `type Optional struct { Value T; HasValue bool }`. And then perhaps, as
>>> the fourth or so step, we may shape our coding practices to better
>>> understand how all this could be practiced in Go source itself.
>>>
>>> --
>>> Gurpartap Singh
>>> https://twitter.com/Gurpartap
>>>
>>> On Saturday, August 19, 2017 at 8:35:34 PM UTC+5:30, Tong Sun wrote:
>>>>
>>>> Suggesting C# type syntax like "int*?*" so as to take nil as valid
>>>> value.
>>>>
>>>> Currently:
>>>>
>>>> var i int
>>>> i = nil
>>>>
>>>> will give:
>>>>
>>>> cannot use nil as type int in assignment
>>>>
>>>> However, more and more people are using json to transport data, and
>>>> there will be times that json may be invalid. I.e., the "int" type has
>>>> 'null' as input.
>>>>
>>>> This is causing tremendous problems for me so far, as I have to jump
>>>> over the hoops to deal with them.
>>>> In C#, just by adding a "?" to the end of the type solves the problem.
>>>>
>>>> Please consider.
>>>>
>>>>
>>>>
>>>> --
>>> 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...@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.
