Package naming conflict

[cypherwytch]

Hi, I have an awkward request to make due to an issue with package names...

I'm working on a FlatBuffers package which implements a proper Nim package for Google's FlatBuffers serialization format (I think you can see the naming conflict coming).

Normally, I'd be more than happy to simply rename my package to something else (like flatbuffers-runtime), however part of Google's FlatBuffers toolset includes flatc, which can be used to generate Nim code to perform part of the serialization task. The main issue is that flatc --nim generates Nim code which expects a package named flatbuffers, but Google doesn't provide a proper nimble package for it (and also their implementation has bugs, but that's unrelated).

Because of their code generator, my package needs to be called flatbuffers to be compatible out-of-the-box, which unfortunately creates a naming conflict for nimble because this package already has the name.

So I hate to ask this, but would you consider possibly renaming your package? If not, I understand and will file an issue with Google to find a solution on their end.

[Vindaar]

Hey,

thanks for the issue! When I wrote the library I wasn't even aware of the Google FlatBuffers package. Someone made me aware of it only after. I simply came up with the name, because it nicely describes what the lib does, namely turn (potentially nested + ref) objects into a flat memory buffer.

However, I don't necessarily need to "occupy" the name given the (more well known) Google package. My lib is still pretty new, so there are likely not many external users. @Cloudperry seems to be one at least. I could update all my personal code with a newer name quickly, that's not an issue.

Mostly out of curiosity, can you expand on how your package works in conjunction with flatc? If flatc already produces Nim code (which as you mention seems to be somewhat broken), how does that relate to your package? Or does it only produce type descriptions or similar that match the flatbuffer schemas in some way?

In any case, I would recommend to still open a PR to the Google repo and make the name adjustable. If only to avoid a similar conflict in the future / help with the already present conflict of the version part of Google's repo (based on https://github.com/RecruitMain707/NimFlatbuffers afaiu). I think the relevant portion is:
https://github.com/google/flatbuffers/blob/fb9afbafc7dfe226b9db54d4923bfb8839635274/src/bfbs_gen_nim.cpp#L186
I can only assume they already have some kind of configuration setup. So making that adjustable seems like a sane thing to do anyways.

I will think about a new name (open to suggestions of course!). And @Cloudperry if you could chime in, that'd be cool too.

[cypherwytch]

Thanks for the reply :)

I think you're absolutely right about opening a PR with Google. Thinking about it a little more after, it's just better for flatc to allow for alternate implementations anyways.

About your other question, the flatc-generated code only produces superficial definitions and procs which ultimately rely on a more generic flatbuffer package, which provides generic methods for reading and writing data to/from the flatbuffer.

flatc's generated code is fine, but the flatbuffer package is the common runtime that's kind of busted, and also requires manually cloning the repo and installing locally with nimble. I don't think it can be properly installed remotely with nimble unless they move it to its own git repo, which seems like it would break how they manage their implementations for the project (though I might be misunderstanding how nimble fetches packages).

Ultimately, my package fits in by both providing an easily searchable and installable package that works as a drop-in replacement for the original package, as well as fixing the bugs (which is done, there were some serious issues with offets being misinterpreted as serialized integer values), and later adding a bit more Nim-specific documentation as well as a more generic format validation function.