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.
Related
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'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.
Is the process of creating a custom command/plugin, such as pg:transfer ( for example ) documented somewhere? I tried searching for this kind of info but I get no relevant results.
Unfortunately there is not much in the way of docs around that. Your best bet is to review examples and go from there. The key is basically that whatever is in init.rb there will be loaded, so you can simply define your additions there (or require the files that define them if it is a larger/more complex plugin). The end result just ends up monkey-patching the toolbelt, so you can also look at toolbelt commands for additional examples. Finally, if you need any external gems you will need to use vendored copies of them. Hope that helps put you on the right track, but let me know if you have further questions.
You have some code you want to remove associated with an obsolete piece of functionality from a ruby project. How do ensure that you get rid of all of the code?
Some guidelines that usually help in refactoring ruby apply, but there are added challenges because having code that isn't being called by anything won't break any unit tests.
Update: Has anyone written anything that allows you to guess based on your version control history if there are commits where you have since deleted most, but not all, of the code and can point out the remaining code?
Current thoughts:
Identify the outermost part of the stack associated with the obsolete functionality: the binary script calling it, or the unit tests calling it.
Look for methods that are only called by methods associated with the obsolete functionality. I often use git grep for this.
In theory, running mutation testing and looking for code that used to be mutation resistant when the old test suite applied, but is now mutation prone might help. It only helps if your code was well-tested in the first place! (Or you can use code coverage tools such as rcov rather than mutation testing)
Running test suites will ensure you haven't removed anything you shouldn't have!
Using autotest can save you time if you're constantly running tests.
If your code was well-structured, it should be easier to find related methods that need to be removed.
Especially in a dynamically typed language, there is no easy way to do this. If you have unittests, thank the developer that wrote them because it will help you remove the code correctly. But you're basically SOL. Remove the code, if it breaks, put it back, figure out where it broke, attempt to work around it, and repeat.
Look at your code coverage. Any code which isn't covered may be part of the code you have left to remove (if any). (Just be sure you have removed you tests. =])
I've just done a major, major overhaul on a colleagues project and throughout the process almost everything got rewritten. There was far too much code beforehand.
Now, I am left with the prospect that in amongst my project somewhere are old pre-refactoring methods that are no longer needed.
Is there a way to search the whole project for such methods in one go?
I understand the risk of potentially removing code used via reflection.
It's very similar to this question, except I would like two extra things:
An answer specific to ReSharper
Instructions on how to achieve this using ReSharper as I cannot seem to figure it out
Use solution-wide analysis.
If you change "Unused declaration" in
"R# Options/Inspection Severity/Code Redundancies/Unused declaration" to "Show as Errors", you'll be able to identify all unused declarations.
As far as I know, there is not way to do this with R# for the entire solution/project. The only way I know of is to go through your code manually, pressing Alt+F7 on each method name.