Go port of Github's Scientist

Hello, I just whipped up a simple port of Github's Scientist and with heavy inspiration from the python port Laboratory (here's the reddit post). I call it LabAssistant. It's a really lightweight port, so it lacks most of the features found in the other projects. If it works any good for some future work of mine I'll go ahead and implement the other features too (pull requests works great too ).

It was mostly made for fun and to scratch an itch, but there's one or two projects of mine I need to do some refactoring on so I thought it would be interesting to try this new approach.

I'm posting LabAssistant to this sub mostly for fun too (I rarely advertise my own work), to see how that would affect the project, and for getting any sweet criticism on my code in general. I would gladly like to be shown any other alternative too!

Newb edit: Of course it helps if you post the actual link, dummy.

Edit2: formatting

---

评论：

dgryski:

You should fix the layout of the repository so that the source code is at the top-level, and the example is in a sub-directory.

That way, go get will work as expected.

For more info, https://golang.org/doc/code.html#Organization

giant_pollo:

Thanks. I was afraid someone would comment on that. I've never been a fan of that official project layout, makes things feel too cluttered in the root directory for me. But I'll go fix it just for you :D

010a:

You need to go with that layout if you're writing a library (meaning no main function).

If you're writing an app, you can do whatever you want. 

giant_pollo:

Could you explain why it's needed for libraries? I get it that it's good idea to follow the usual conventions when making a public library, but besides having a barely longer and less comfortable import path (with the /src at the end), I don't see any bigger problems with my original layout. The go tools still work just fine for me?

I have a faint memory of trying to research why, but I think I never found any good reasons and decided to just go with my own approach anyway.

RandNho:

To use a library, you include it by path and call functions with library name as prefix. 

And your library isn't called src.

giant_pollo:

That's why the package keyword exist, right? It shouldn't matter which directory the library files are stored in, as long as you import the correct path where they are found. 

I'm sorry, I might be thick headed or something but I still don't see the need to keep the source files in the root dir.

Edit: fixed the link.

barsonme:

goimports breaks if the package's name is not the same as the last segment of the import path, and it's annoying. Renaming a package import (e.g., foo "github.com/user/bar) is annoying as well.

giant_pollo:

Hmm alright, that makes more sense. I personally haven't had any problems with the go tools, so I wasn't entirely sure my old layout was messing up something for someone else.

In any case, thanks for helping out guys.

barsonme:

you're welcome. hope i didn't sound mean with all the 'annoyings', lol.

XANi_:

You might want to read a bit how godoc and templates work.

You can do neat tricks with it, like code template that gets compiled and checked with normal tests (and included in relevant docs section), so if you accidentally break it go test will catch it

giant_pollo:

I'm familiar with godoc and have used templates a lot for my web apps.

Didn't know you could test the code examples in the docs though, thanks! Also, is that a friendly wink at me to get started on the tests sooner? ;)

XANi_:

Look at http://goconvey.co/ especially if you use 2 monitors.

You just run it and it automatically runs test whenever any file on disk changes. It has also few nice builtins to make writing tests easier, like a bunch of asserts for various data types.

giant_pollo:

Yep, I've used it in the past. It's pretty sweet, but I remember having had troubles getting a coverage report from it. It's probably easier to use now a days.