3 ms·

I've been experimenting with it as well and it looks like you have to copy several directories to get it to work out of the box - templates, public, custom, log

I've been experimenting with it as well and it looks like you have to copy several directories to get it to work out of the box - templates, public, custom, log, and data. But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. What we've done for our internal Go projects is wrap them up with an .rpm installer that handles the creation of directories throughout the system, drops init scripts where they're appropriate, and sets up necessary cron jobs and logrotate rules. I don't think this is the best approach, but at the same time I'm not familiar with any good alternatives.

andmarios 12y ago
If the project permits it (size, complexity, what kind of bugs I expect to encounter) I like to have my static assets in a separate git repository. System configuration I think is a problem independent of the programming language and anything you try will feel as hack. As long as it works, it is ok. :)
elithrar 12y ago
> But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. This is mostly a sysadmin/devops issue, since all languages have the same issue. I solve it through a CM tool (Ansible, in my case) that sets up my directories, rsyncs my templates and TOML config, and uploads my binary. Not having to worry the server running the same env as my dev environment removes a whole class of bugs/frustration.
- serverhorror 12y ago
  > This is mostly a sysadmin/devops issue, since all languages have the same issue. You're kidding right? I thought that whole "devops" movement (call it what you like) was to get rid of the attitude of "other people's problem". I live in environments that are (for the most part) regulated and demand by law that there is a strict separation between the people running and developing software, often open to interpretation is the 3rd role of people configuring the software. The problem is that "I solve it..." just doesn't work. Either people solve it by working cooperatively together or it simply won't ever be deployed. There's no such thing as a sysadmin problem, devops problem, developer problem. (No go downvote me for the tone of the next sentence) -- For me it's either get your ass moving, stand up, walk over to people and talk to them or get lost!
  - elithrar 12y ago
    I missed this at the time, but I think you read past what I said: I used "devops" in the tools sense, not the people sense. A programming language (the syntax, the compiler, the linter) can't be everything to everyone, and therefore most don't attempt to shoehorn in things like static asset bundling, etc. That's why frameworks exist, or packages like go-bindata or rakyll/statik (https://github.com/rakyll/statik https://github.com/rakyll/statik), or CM tools that can wrap it all together.

andmarios 12y ago

If the project permits it (size, complexity, what kind of bugs I expect to encounter) I like to have my static assets in a separate git repository. System configuration I think is a problem independent of the programming language and anything you try will feel as hack. As long as it works, it is ok. :)

elithrar 12y ago

> But I'm inclined to agree that this is one area Go projects have a hard time with. The portability of the executable is great, but if you're doing anything that requires static assets, configuration, or data outside the context of the runtime, you can easily end up with a tough-to-manage mess of configuration. This is mostly a sysadmin/devops issue, since all languages have the same issue. I solve it through a CM tool (Ansible, in my case) that sets up my directories, rsyncs my templates and TOML config, and uploads my binary. Not having to worry the server running the same env as my dev environment removes a whole class of bugs/frustration.

serverhorror 12y ago
> This is mostly a sysadmin/devops issue, since all languages have the same issue. You're kidding right? I thought that whole "devops" movement (call it what you like) was to get rid of the attitude of "other people's problem". I live in environments that are (for the most part) regulated and demand by law that there is a strict separation between the people running and developing software, often open to interpretation is the 3rd role of people configuring the software. The problem is that "I solve it..." just doesn't work. Either people solve it by working cooperatively together or it simply won't ever be deployed. There's no such thing as a sysadmin problem, devops problem, developer problem. (No go downvote me for the tone of the next sentence) -- For me it's either get your ass moving, stand up, walk over to people and talk to them or get lost!
- elithrar 12y ago
  I missed this at the time, but I think you read past what I said: I used "devops" in the tools sense, not the people sense. A programming language (the syntax, the compiler, the linter) can't be everything to everyone, and therefore most don't attempt to shoehorn in things like static asset bundling, etc. That's why frameworks exist, or packages like go-bindata or rakyll/statik (https://github.com/rakyll/statik https://github.com/rakyll/statik), or CM tools that can wrap it all together.