I'm writing a fairly simple application in Go, more as a learning tool than anything else.
What I'd really like to do is to organise my code somewhat - for example, I've separated out some Hipchat API commands into a separate file. Right now, it's still under the main package, but I'd prefer to move it (namespace it) into a kind of subpackage. The thing is, Go seems to think that such a package should live in my $GOPATH, despite it not being relevant to any project besides the one it's being written for.
I'm probably trying to misuse the package functionality, so if so, what's the best way to achieve what I'm trying to do?
Thanks to the pointers from tkausl in comments left on my question, I figured out the way to achieve exactly what I wanted. I moved my project to reside in $GOPATH and then accessed the sub-package via import subpackage from "project/subpackage".
Wouldn't have got there for a while without that help! Just a case of learning Go's way of doing things.
Related
How to move a function/type from one Go file to an other Go file in vscode?
... and the IDE should update all usages of the moved function/type ...
In the past I used Python and PyCharm, and it supported this kind of refactoring.
It seems that this feature (the move-refactoring) hasn't been implemented in VSCode yet. The only workaround that just came into my mind is this.
You can use the cmd gomvpkg to move a package to a new one. Thanks to this, if you have only the function within the file you should be good to go. It should also update the import statements (make sure to double-check them anyway). I know that it's boring in fact I keep copying/pasting functions between packages as it's faster.
It seems that this feature is already supported in Goland, so you can give it a try maybe if you wish.
Let me know!
A bit of background:
I am a pentester who is looking for new ways to get around AV detection during tests / bounties and I recently found the Go library "Coldfire" on Github. I am new to Go so I was wondering how I would structure a project with this package.
It doesn't give much instructions except the func that it uses and I am coming from Python.
https://github.com/redcode-labs/Coldfire
If anyone can give me some tips, I am trying to write an AV evasion program that will kill AV processes and possibly disable a WAF.
You don't have to give me full code or anything, I just would like some examples on how to use the package is all. Thank you so much and please excuse my lack of knowledge I love Go but am very new to it and trying to learn it respective to my profession.
Not really interested in Disruptive functions but with the recent outbreak in Go malware I would love to understand how malicious attackers use those functions too if possible.
I imported the library but it kept giving me an error saying I wasn't using the package even though I had implemented some of the functions to see what they did.
Not sure what goes in said func like..
func PkillAv()
Not sure what would go in the {} on this one or if I would even need it.
You would just need to import it at the top part of your code like:
import "github.com/redcode-labs/Coldfire"
You also need to run
go mod tidy
To download this package.
After that you can use the functions provided in the package. There is no "structure" that you need to manualy create
I needed to write my own lightweight GO multi-output logger for a work project and I've come up with https://github.com/asticode/go-logger.
I'm not here to advertise at all and I'm rather looking for Gopher's opinions (good or bad) on my code and my implementation since I'd like to know whether I've done things right or whether I've gone completely off tracks.
My points of emphasis would be:
Have I made good use of interfaces?
Have I made good use of const and global vars ?
Have I made good use of GO project structure ?
Have I made good use of GO unit testing package?
...
I really thank you in advance for the time you'll put in reviewing my project.
Cheers
Quentin
If your writing a go command (not a package) that is large how do you layout its internals? I would love to have some utility packages etc but not have those exposed for anything except the command's code. If it's all in the same repo I don't see whats stopping someone from importing those internal use packages.
You might make your utility packages internal to your package — like this. This won't prevent anyone from using them but a) why would you care anyway? b) the package's structure would give a clear hint on that these "subpackages" are internal to the project.
The answer is simple (but most probably not what you'd like to hear): Do whatever you like and is allowed. Having utility packages living somewhere is perfectly fine, either in the same repo as a "sub-package" or in a different repo.
Regarding
I don't see whats stopping someone from importing those internal use packages
Why do you care? If the packages encapsulate distinct and usable functionalities someone might benefit from importing them. Keeping those function together with the command does not "protect" them in the sense of "nobody should be able to look at my code". Just make it clear in the docs that you'll feel free to do incompatible changes at any time. Go is not about preventing each and any stupidity and protecting the lazy and incapable ones who deliberately ignore any documentation from shooting their foot.
I'm writing a web application in Go. So far I've written all base libraries I'm going to need for now and that worked out just perfect. The package structure is really handy in that aspect.
Now I'm at the point where I need to start writing the application itself, the business logic. I'm a little lost of how or where this code should go.
I've watched and read pretty much every application development tutorial/walkthrough on the official documentation page and they always write the entire domain logic in the main package/namespace.
Is this the way to Go (sorry, had to) or was it just for the sake of simplicity?
Putting the business layer into packages feels uncomfortably wrong in my opinion.
No, it does not have to be all in the same package. You can easily make a new directory, put your code for that package there, and import it from your main package. It's simple as that.
You may want to look at go-tour as a simple web app that consists of a few small packages (pic, wc, ...). If you want to see organization of a big Go app see Camlistore. Both of these are written by Go Authors, so they can be considered nice examples.
I just have to say that writing small, reusable, and separate packages is very common in Go, and that reduces the size of the main codebase of apps.