[go-nuts] Re: Unable to represent a file data type

[Ronny Bangsund]

On Tuesday, September 8, 2020 at 7:44:33 PM UTC+2, Qali Fah wrote:
>
> The problems i'm having are how i would represent the artwork(picture 
> file) and song (music file) in gorm (Golang ORM library) and in what format 
> do i return it to the client after being stored and are there external 
> packages i can use to simplify things?
>
I'd use filenames locally and return URLs to media. Reference the music and 
image files rather than stuffing them into the database. Store names, 
filenames and all the metadata you think makes sense (artist, album, genre 
and all sorts of extra tags) in the music file table.

If presenting a web API, JSON is perfectly fine (and most common). Any web 
frontends are likely to be JS anyway, so use a natively easy to use format. 
The built-in packages in the Go distribution can get you all the way, but 
if you like a little extra help with routing, Chi is a decent option:
https://github.com/go-chi/chi


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eb1a0231-c95f-4443-8f33-a273039bff50o%40googlegroups.com.

[go-nuts] Re: Is it necessary to start function names within main package with capitalized letter?

[Ronny Bangsund]

I tend to do it too, because at some point I often find that I might as 
well create packages (internal or not) from some of the functionality. For 
example, my latest little tool wraps some AWS functionality with 
pretty-printing and progress bars, and I suspect I may find use for those 
in other programs later. I write comments and exportable funcs no matter 
what.

And like Axel Wagner implied, team consistency is important too. If there 
isn't a linter which could help enforce a policy, that's an idea for a tool 
I'd use…

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/29f80672-f984-4166-adfd-d0d5e9e35b87o%40googlegroups.com.

[go-nuts] Re: For a .net developer,how long it takes to learn go completely?

[Ronny Bangsund]

I'd say the more C-like languages you know, the easier it is to become 
fluent in Go. If you've already gotten used to switching between the likes 
of C, C++, C#, Java and more, you're likely to have fewer wrong assumptions 
about Go. Getting over the error handling verbosity is the major first 
step, I think :)

On Thursday, June 11, 2020 at 7:33:32 PM UTC+2, derek kenney wrote:
>
> There is a lot to Go. I'm still learning after three years. I will never 
> go back to .NET after moving to Go. Good luck. 
>
I miss things from C# in Go and vice versa. But C# isn't as useful in the 
Linux environments I prefer, and Go works well for both CLI tools and 
server software/glue.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/52524822-b864-444a-b575-95f3f2503f69o%40googlegroups.com.

Re: [go-nuts] Re: gzip.Reader.Read does not fill the given buffer

[Ronny Bangsund]

Reading in small chunks is handy for progress displays too.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/115eb9de-b821-44ae-a91c-b8dde26c28beo%40googlegroups.com.

[go-nuts] Re: gzip.Reader.Read does not fill the given buffer

[Ronny Bangsund]

On Tuesday, June 9, 2020 at 4:05:38 PM UTC+2, Amit Lavon wrote:
>
> I am reading raw bytes from a gzip input. I found that it only reads up to 
> chunks of 2^15 even though there is more data to be read.
>
> Is that the intended behavior? I expected whatever internal buffering it 
> may have to be invisible to the caller. If that's intended, how could I 
> have anticipated that? The contract of Reader 
>  says "Read conventionally returns 
> what is available instead of waiting for more" but it doesn't seem to be 
> the case here.
>
We're at the mercy of what the filesystem prefers to give us, and in my 
experience it likes many small chunks on any OS. I've seen consistent 
returns as low as 4k from plain file reading, so 32k from gzip 
decompression seems good. Behind the scenes the OS may already have 
buffered your entire file if it's not too huge, so I wouldn't worry about 
it being slower to loop through small buffers repeatedly.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/53405eec-3335-4f47-a503-594e9372a3f7o%40googlegroups.com.

[go-nuts] Re: How to work with multiple environment like dev, test, staging, prod in golang ?

[Ronny Bangsund]

On Sunday, May 17, 2020 at 7:19:23 PM UTC+2, Shishira Pradhan wrote:
>
> In springboot, we have configuration like port, database etc info are 
> stored in yaml files like application-dev.yml,   application-test.yml, 
> application-prod.yml profiles, and profile name is passed during running 
> the application to load profile specific configuration. I need to 
> understand that how to load/pass profile based properties in golang ?
>
I use Docker a lot at work (everything we do runs on AWS or Google 
servers), and that makes separating things relatively simple.

AWS has different environment variables for different configurations, 
allowing one Docker image to run with different settings. With 
docker-compose you can tie together tailored Dockerfiles and different 
images for different purposes, as needed. I recommend having a default 
"docker-compose.yml" be the dev environment, with its own environment 
variables, and variants for staging/prod with other names expecting envvars 
from the system it's running on. This makes the default invocations of 
docker-compose launch in local dev mode.

We use a lot of Python (Django, Wagtail) which expects envvars anyway, so 
it's a natural way to do things there. For Go I either write AWS-specific 
things which only expect envvars, or use a configuration system which 
overrides config files with outside vars.

We haven't started using Kubernetes yet, but the process probably won't be 
much different.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7c421559-8a25-450b-9e4f-b48e72f8f985%40googlegroups.com.

[go-nuts] Re: go run requires internet connection?

[Ronny Bangsund]

On Thursday, April 9, 2020 at 1:01:31 PM UTC+2, Tanmay Das wrote:
>
> Running the executable: `./helloworld`
>
Maybe there's a log entry for your program specifically in Console (the GUI 
collecting macOS logs), or in one of the system logs.

If this is somehow related to GateKeeper, you could try making an exception 
for it:
spctl --add helloworld
(You'll get a popup to enter the admin password.)

Or removing all attributes:
xattr -d 

Although I'm not sure the last option will do much :)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4fb656e2-2600-41de-a298-d74f628d7a00%40googlegroups.com.

Re: [go-nuts] Is it possible to build Linux executables on Windows with lxn/walk?

[Ronny Bangsund]

On Thursday, April 9, 2020 at 6:03:24 AM UTC+2, 洪嘉鴻 wrote:
>
> Excuse me.
> Did you mean this ?
> Thank you very much!
>
Yes, that's the one, Docs at https://fyne.io and the cross-builder/packager 
at https://github.com/lucor/fyne-cross. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/25d4fefe-cc43-4664-b2a8-9c86f3c696aa%40googlegroups.com.

Re: [go-nuts] Is it possible to build Linux executables on Windows with lxn/walk?

[Ronny Bangsund]

On Thursday, April 9, 2020 at 5:01:02 AM UTC+2, 洪嘉鴻 wrote:
>
> I want to run executables on both Windows and Linux.
> I don't think it is convenient to maintain 2 codes with lxn/walk on 
> Windows and go-gtk3 on Linux.
>
Yeah, it gets messy quickly. It can be done, but then you're probably 
writing another abstraction layer anyway.
 
I started on a hobby project in Fyne today, and combined with fyne-cross I 
had Linux, macOS and Windows building up and running within minutes. There 
are some elementary widgets and features (mainly listviews, treeviews and 
systray stuff) I wish for, but their development process means they'd 
rather have something working than ship half-done features. That sort of 
thing makes me think it's the most promising Go GUI/app framework right now.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/48294158-4cd0-4d84-a07a-4c71d872c8a6%40googlegroups.com.

Re: [go-nuts] How to execute a command using root?

[Ronny Bangsund]

On Saturday, August 31, 2019 at 3:14:28 PM UTC+2, Jakob Borg wrote:
>
> On 31 Aug 2019, at 12:33, Ronny Bangsund  > wrote:
>
>
> Digging through my vast mess of code, I found this function which sets the 
> real and effective user (Setreuid) of the calling process:
> func DegradeToUser(uname string) error {
>
>
> Doesn't this suffer from the issue of only affecting the current thread on 
> Linux, and hence not being safe to use from Go?
>
No idea if Setreuid() works any differently than Setuid(), but I wouldn't 
rule it out. Paranoia should be the default state :)
 

>
> Setting the uid/gid as part of starting a child process should be safe 
> though (https://golang.org/pkg/syscall/#Credential).
>
Yeah, using that with StartProcess() might be a better idea.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a5a93fdf-6079-44d7-a83a-3ebc2d4080d0%40googlegroups.com.

Re: [go-nuts] How to execute a command using root?

[Ronny Bangsund]

On Saturday, August 31, 2019 at 10:07:59 AM UTC+2, Chris Burkert wrote:
>
> is there some code available to dig into that? I plan to do something 
> similar that a regular user process starts up a kind of a root broker which 
> starts several other processes as different users.
>
You would by necessity have to launch a root process, which then degrades 
to whichever user it should actually run as. It's a one-way operation, no 
backsies :)

Digging through my vast mess of code, I found this function which sets the 
real and effective user (Setreuid) of the calling process:
func DegradeToUser(uname string) error {
uid := syscall.Geteuid()
if uid == 0 {
u, err := user.Lookup(uname)
if err != nil {
return err
}

uid, err := strconv.Atoi(u.Uid)
if err != nil {
return err
}

gid, err := strconv.Atoi(u.Gid)
if err != nil {
return err
}

err = syscall.Setgid(gid)
if err != nil {
return err
}

err = syscall.Setreuid(-1, uid)
if err != nil {
return err
}
} else {
return errors.New(ErrorNotRoot)
}

return nil
}

An error string is the only thing missing (ErrorNotRoot), otherwise it 
should be complete.

Especially for the communication part I don’t have a good and secure idea 
> so far.
>
My hammer is gRPC if I need something with a little security. It's a bit 
convoluted initially, but allows authenticating via certificates. If you're 
running everything on one system there might be better ways,

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/46eebc67-ed8f-4f48-b27c-a9af81d22ac8%40googlegroups.com.

Re: [go-nuts] Goroutine scheduled 10 seconds too late

[Ronny Bangsund]

On Friday, August 23, 2019 at 5:58:44 PM UTC+2, Michael Andersen wrote:
>
> It can take a while to reproduce, so it might be a week or so before I 
> have the results.
>
Can you think of ways to cause the same memory pressure quicker? Mocking 
data, running the functions the number of times they would have run in a 
two-week period etc.
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d3d080e0-30d5-4a5c-b5fd-5014071f3bfc%40googlegroups.com.

[go-nuts] Re: Need help to learn go lang

[Ronny Bangsund]

Brian's list is good.

I started with the tour and picked relatively simple tools I wanted to 
write, then looked up what I needed as projects advanced. My list of GitHub 
Go projects is getting unwieldy now, a few years later. It's an addiction. 
Just start with simple projects and set some increasingly advanced goals as 
you learn. It doesn't matter if you're recreating something that exists if 
you're learning from it.

Reading the docs for the included packages should give you an idea of 
what's built in, and it covers a lot. The basics to fetch and serve HTTP, 
sending mail, doing RPC and most of what you're likely to need in crypto, 
although sometimes a 3rd party may provide an easier/better way to do 
things. If you're building web servers you may need some middleware too 
(neater REST endpoint setup, authentication, rate-limiting).

There's a newbie channel on the Gopher Slack (you have to join it manually, 
as you only start with #general) where you should be able to get some help 
with specifics. Just start something and ask as you get stuck!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6bd2bf85-55e5-4cc5-a87a-d2f5b0001e1a%40googlegroups.com.

[go-nuts] Re: Project Layout Question

[Ronny Bangsund]

On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote:
>
> Is the project layout total rubbish?
>

I'm not sure - all I know is that it's different from how I prefer it, and 
"pkg" is the one thing I frequently see people dislike ;)
If you want to share packages, parent them to the project directory. 
Anything you feel is too niche you can hide inside internal/. Binaries in 
cmd/ makes it nice and tidy, but you can get away with top-level main 
packages if there's only one command and it's really simple (few source 
files to clutter it up).

I might make a server cmd the same name as the project directory, and if 
possible, make it have CLI options to control itself (talk via local 
socket, gRPC, REST, whatever). Pleasing VS Code is mainly about configuring 
the build task(s). I like to have Release and Debug tasks, sometimes with 
tasks requiring other tasks (client-server projects, for instance).

So one of my web server app layouts might be something like this:
foo/
|--foo (binary)
|--auth/
|--
|--static/
|--css/
|--js/
|--tpl/

While a tool with some less standard packages of utility content might look 
like this:
bar/
|--cmd/
| |--binary1/ (and so on)
|--
|--internal/
|--

I try to give server/client parts of a multi-binary system somewhat useful 
names, even it it means a little "stutter". For instance, the server app 
might reside in "foo/cmd/foo", and the manager is in "foo/cmd/foomgr/". I 
don't really like hyphens and underscores in names, but I'm not sure if 
there's any technical reason you should use them. It might be a matter of 
taste. Some programs might have "foo" as the main command, and the other 
"foo-" commands are possible to run alone, but also hidden behind options 
in "foo".

I also decide from time to time that I hate everything about my project 
layouts and redo everything, so don't consider this advice, or even useful.

I haven't looked closely at the current state of modules to say anything 
about how it'll change up my standards, but it looks like we're expected to 
run module stuff out of the top-level directory. If not, aren't those parts 
better off breaking out into their own standalone projects? Running module 
setup in sub-directories with potentially different versions of external 
dependencies feels dirty.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b5d4160c-035d-477c-bdda-23c7ea366cb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Ronny Bangsund]

Yes, the built-in is pretty awful in many ways. There are fortunately lots 
of alternatives, all with roughly an order of magnitude better performance. 
I inspected this list yesterday to finally make a choice of packages to 
use: https://github.com/smallnest/go-web-framework-benchmark

I ended up with the following as my weapons of choice:
- https://github.com/valyala/fasthttp (the core HTTP server)
- https://github.com/fasthttp/router (paths)
- https://github.com/phachon/fasthttpsession (sessions/non-REST stuff)

There are other packages near the performance of fasthttp, and sometimes 
you just want "good enough" performance to gain some conveniences. Most, if 
not all, are likely to be better choices for performance than the Go http 
package. The ones above just looked most agreeable to me :)

For template engines, it depends on your needs. If you're preparing pages 
to serve them statically the standard packages are fine (html/template, or 
even text/template for certain uses). If you're constantly rebuilding pages 
you'll want to look into faster template engines.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/19767e83-c498-4842-b41c-145730775c05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go+ replacement

[Ronny Bangsund]

I occasionally read this list, and sometimes I stop by the Go Slack. There 
are many channels there, and the general one might actually be the least 
interesting to many. I mostly follow the VSCode discussions/live help 
channel, and sometimes there's activity in other project-specific or 
regional channels.

Browsing #golang on Twitter sometimes at least shows some interesting 
projects. Maybe even people to follow.

-- 
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.

[go-nuts] Re: binary protocols code generators (parser/writer/validator/[de]serializer)

[Ronny Bangsund]

Protocol Buffers springs to mind. It's a compact binary protocol with 
predefined field order, allowing you to skip unused fields and maintain 
backwards compatibility. You could probably use it as a storage format too. 
It's not in the Lex/Yacc territory, but it DOES generate all the code you 
need to handle the defined structures.

Protobuf is the message definition, and it goes hand in hand with gRPC to 
generate client code plus server code stubs for secure network 
communication with optional streaming:
https://developers.google.com/protocol-buffers/
https://grpc.io

If you're looking for tools for existing binary formats, I dunno. Protobuf 
would only be halfway there, as I don't think it supports unions with 
overlapping fields as you could find in some (like the PE binary format for 
Win32/Win64).

-- 
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.

[go-nuts] Re: Unix binary installations for Go

[Ronny Bangsund]

Which Unix/derivative? The great thing about them is that they have so many 
standards to choose from ;)

"go build" isn't sufficient for most of my projects, if I want proper 
distribution of binaries. I might use "go generate" to create some 
data/source a program depends on, and I always embed the version tag as 
returned by "git describe --tags  --abbrev=0"  in the binaries with 
the -X flag. That requires a build script of some sort.

If you package with any common Linux distro's tools it's expected that the 
packager has a full build environment. It would of course be useful if you 
included a script to "go get" everything the build needs, and that can 
usually be done in pre-build hooks in these packaging systems.

If you're building server apps maybe you'd consider packaging as containers 
instead. If they're command line tools you're still going to have to 
consider the target OS and its conventions, but you can make the binary 
quite self-sufficient with per-platform source files or/and go generated 
settings, so that they look for or create a configuration file.

I don't think the packaging itself is a problem, as there are tools like 
dh-make-golang to massage Go into Debian-derivative packages. You just need 
to specify and dependencies like databases, discovery services and so on 
you require.

For my own stuff I make the programs themselves flexible enough that there 
aren't any hard requirements for configuration files and their locations, 
but Linux builds have a fallback to /etc// for server stuff, 
$HOME/./ for CLI tools, and macOS builds use 
$HOME/Library/Application Support//. I always leave in the option 
to specify an alternative path via -C or --config.

The config files define where to load all the other data and any logging 
options (/var/ and /log/ are possibilities there).

-- 
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: need library suggestions on writing a record program

[Ronny Bangsund]

On Tuesday, November 29, 2016 at 7:11:57 AM UTC+1, bia...@gmail.com wrote:
>
> I've been wondering how I should setup input fields. should termbox be 
> responsible for it? or termui as you suggested (this  seems more for 
> monitoring...) or even gocui?
>
 I've tested termui and GOCUI extensively, and found both to be the best 
options for exactly that sort of thing. I did have to modify things/make 
custom widgets to get lists working how *I* like them, but it's very easy 
to use.

I'm leaning slightly towards GOCUI personally, but that doesn't mean you 
should reach for that without testing termui. Both are fairly easy to set 
up, but they have different ways of handling input and updating the display.

If anyone is kind enough to show some example code of a page with input 
> fields maybe 1-2 input fields it'd greatly help.
>
 There isn't really much to it. There are very few widgets - everything is 
basically a bit of text, with or without a border, with different colours 
and/or cursors to indicate its purpose. Examples of what you need would be 
useful.

For more direct help I can recommend the Gopher Slack (I can show more of 
my code there).

-- 
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.

[go-nuts] Re: Golang should have a center packages index hosting like npm, rust crates

[Ronny Bangsund]

On Thursday, October 20, 2016 at 5:45:03 AM UTC-0:8, zixu mo wrote:
>
> Golang should have a center packages index hosting like npm, rust crates.
>
It seems some posters didn't notice the distinction you made there ;)

The OP asked about an *index*, not a central repository. It would basically 
be (a variant of) go get with an additional index of third-party package 
URLs. Take a look at http://crates.io for the simplest example. Everything 
there links to the authors' repositories (which these days basically means 
everybody's fave egg baskets, GitHub or BitBucket).

(Enter the Dreamlands for a bit)

My ideal system would have a few typical package manager features, like 
versions with individual dependencies for each, categories, priority levels 
for versions and some way to switch between versions/branches easily. Make 
mirroring and hosting the index easy. Dependencies could also be figured 
out via package contents, but sometimes a newer version also relies on 
specific versions of other packages - this could fail horribly in a 
downgrade when APIs change.

With all of the above covered, now you'd need to get people to use it, 
automate as much as possible and avoid name clashes. Package names in the 
username-package style might work, but the command line tool then needs to 
be able to suggest package names ("No package foo. Did you mean foo-bar or 
foo-bar-baz?").

Of course, a pure index solution wouldn't automatically be tracking package 
popularity in any way. It just serves up URLs for go get, and knows nothing 
of what people actually download beyond the index (unless it has optional 
stats tracking sent back to the index site).

The case of packages relying on cgo is also a problem. At that point you'd 
require some advanced pre-/post-install scripts too. Or be lazy and include 
a document with compilation instructions for dependencies.

I can see many problems with both an index and a real package repo, but I 
can see advantages too. It would be relatively simple (for variable values 
of simple) to get tools and a backend ready if focused on pure Go. It would 
just take a little effort from package developers to be as smooth as 
possible.

-- 
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.