dustinkirkland / golang-petname Goto Github PK

This is fairly obvious after taking a peek at the source and seeing the use of rand.Intn. That said I think it would be a good idea to add a note in the Readme about this and recommend setting the seed before generating any petnames using the library. If this is the case and I'm not missing something I'd be happy to spin up a PR.

Thanks for the library!

You've got this function calling rand.Seed for a non deterministic mode.

However, since go 1.20, rand is automatically seeded, unless explicitly disabled:

// Prior to Go 1.20, the generator was seeded like Seed(1) at program startup.
// To force the old behavior, call Seed(1) at program startup.
// Alternately, set GODEBUG=randautoseed=0 in the environment
// before making any calls to functions in this package.

Maybe you want to factor this behaviour in, not sure. For me personally, I called rand.Seed manually beforehand and simply had no change in behaviour. But for people expecting something deterministic, this might be confusing. Additionaly, this library might want to stop using globalrand and instead allow specifying a source, as this makes it easier to use within projects that use randomness for other purposes.

Hi,

We'd like to use your library to generate nonces but I'm concerned about the init() function that's included in petname.go. This init() will be called on startup and could conflict with other calls to rand.Seed().

In our case we have some code to alternate between a specific seed in order to repeat a test run and time.Now().UTC().UnixNano() for psuedo-random behavior.

Would you be open to simple PR to move the init() into https://github.com/dustinkirkland/golang-petname/blob/master/cmd/petname/main.go? This shouldn't affect the behavior of the petname utility but it will make it easier for us to reuse the library.

Thanks,
brian

This came up on reddit: https://github.com/zippoxer/petname/
https://www.reddit.com/r/golang/comments/bfjhhe/petname_a_go_package_that_generates_silly_pet/
He seems to "credit" you but that's not the same as following your license.
He's had 3 days to fix it. He's commented on elsewhere under the post, and added that "credit" commit, so I assume he has seen the comments.

This may be interesting and funny, but I have just actually received holy-crappie from a call to petname.Generate(2, "-"). It happened when using random_pet Terraform resource and now I have AWS resources tagged with that interesting name.
It's not a problem in a test scenario, but I'd prefer to avoid such nasty surprises in production. What do you think about adding a filter for forbidden combinations to the code? I'm not sure how long the "naughty" list would be, but it might be interesting to think about other possible examples.

Hi,
Nice tool!

Would you be open to publishing a simple Docker image on Docker Hub for this?

For Incus (ex-LXD), we like supporting the past two major Go versions, that is, 1.20 and 1.21 currently.

Your recent change to introduce a go.mod came with you setting a minimal version of go 1.21.1 which is therefore breaking us.

I don't see any reason for petname to require 1.21.1, so you should be able to just go mod tidy --go=1.20 to set the base version to 1.20.

Please tag releases of this library that correspond to the versions you list in debian/changelog. Doing so will greatly help individuals who are packaging this library and using something like a watchfile to track new releases.

(I'm working on updating Debian's version of this package, and due to a historical decision about the versioning of Debian's packaging, Debian's version is a mashup of <version>+<git commit>. Proper tagging would eliminate this less than ideal situation.)