be able to control randomness of boundary headers #276
Conversation
|
I'm in favor of this feature, but I think we need to move away from using a global variable for the random source. If your code, or its tests, run in parallel, you will clobber the random seed and will not get deterministic output. Perhaps we can store a randsource reference & mutex in the builder, then pass it into UUID()? |
|
sure, thanks, that was my first thought as well, but then saw that threading it through the code might be cumbersome, having to go through |
|
I just threaded Parser into Part a couple days ago, it may be possible to leverage it and the Options stuff to get the random source into the right place. |
|
i've updated this pull request with a specific |
|
Overall I think this is a good approach, but I don't think we should add the functional options pattern to a builder, as those are two ways of doing the same thing; mixing paradigms will be confusing. It also breaks the re-usability pattern I want the builder to support, where you can setup a root builder a specific way, and then re-use it for multiple emails. There is no way to reset the rand source for each of those. Let's just define a |
|
got it thanks, i'll re-work it that way. |
… rid of global rand lock
|
please take a look at updated request which i believe satisfies your requirements, thanks! |
|
Thank you! |
|
thanks! |
in order to create reproducible email messages, i needed reproducible uuid strings which are used for boundary headers. therefore, i added a new top-level method
func SetRandom(r *rand.Rand)which causes the UUID function to use that given Rand object. for instance, in my project i call it likeenmime.SetRandom(rand.New(rand.NewSource(1))). in the absence of such a call, it is initialized liketime.Now().UnixNano()as before.