Offer an alternative name/namespace
Closed this issue · 31 comments
Unfortunately, libmpc is already a very well-known library in wide-use. I do not think the project's name itself needs to change (or even necessarily should be changed). However, if #93 gets merged, we could leverage the $(PROJ) variable to allow the namespace (and generated library name) that is used for function calls.
In fact, this wouldn't even be that difficult to change. It would just involve some code like this:
#ifndef NAMESPACE
#define NAMESPACE mpc
#endifAnd then using -DNAMESPACE=$(PROJ) when compiling (and changing the generated library name and header file name to use $(PROJ)).
Now, knowing that this is not too difficult to do, is this something that would be considered?
Now that #93 got merged, I am going to start looking into this. I would really like to be able to package this for archlinux. I intend to use the name mupc (as in μ) when I go to package it as that name seems to be much less commonly-used.
I think it would be good to have a name change (I regret the name now), however I wonder if it is easier to just try to change the name directly rather than have a namespace option. I know it will break various things but maybe better in the long run. What do you think?
I agree that a complete name change is a cleaner solution.
I think a name change is likely the better and simpler option; I just didn't want to push you to do so (names can be personal and important) if the name was/is meaningful to you.
Personally, I might recommend micropc or mupc as neither seem to be oft-used names, but keeps the same spirit as the original name.
Good suggestions. It seems "libmupc" shows up some results on google. It would be nice if there were another short name we could use but its hard to find anything that seems to turn up nothing...
Either way any name change will take a long time for me to get around to - so don't hold your breath.
If you settle on a name/namespace combo you like, let me know; I can happily take a shot at a PR for it in the nearish future (if you would be amenable).
You can loop through SI-compatible prefixes, e.g. micro, nano, etc until you find a good name:
- Nano Parser Combinators - NPC
- Pico Parser Combinators - PPC
- Atto Parser Combinators - APC
- Zetto Parser Combinators - ZPC
- Yocto Parser Combinators - YPC
At the risk of this becoming a bikeshed discussion, I have another proposal for a name: “parce que” (in French, literally, “because”). It lends itself to a namespace that appears to return no results anywhere I search for it: libpcq / pcq. Additionally, its pronunciation happens to fortuitously include something very close to the Enlish “parse”.
It could also lead to fun, tongue-in-cheek answers to questions that I imagine you have been asked about projects like this:
- “Why would you do this‽”
- “Parce que je peux” (because I can)
Great suggestion - I like the three letter pcq
Fair enough :) Mind if I start on a PR to update the namespace/project name, or would you rather I hold off?
Feel free although take into account it may take me a long time to process this - it will require making a new github repo as well as updating my book which uses this library.
Why would it require a new repo? GitHub allows renaming. And I thought about the book as well; there's no chance it is open-source as well? If so, I could include it in the rename.
Yes sorry your right not a new repo but re-naming the old repo although in effect it does the same thing and creates a lot of broken links etc.
And yes the book is open source:
Excellent. I have a fork of the book as well. I will see if I can get started on the PRs here in a bit. I figured that, for the most part, s/mpc/pcq/ and s/MPC/PCQ/ alone would actually cover most of the rename, but I will, of course, be more careful than that :)
Anything else you'd like me to take a look at for the rename?
Hi Sam,
Sorry so much for taking so long with this! I will try and set some time aside next weekend.
Dan
Dan,
No worries at all! Please don't feel pressured to set time aside that you don't have. I just want to make the review as smooth as possible and if there is anything else you could think of that I should take a look at first, let me know! ☺
As a side note: my recommendation for merge procedure would be to actually take the rename branch, merge it locally and open a new repo with the new name. Then, archive this repository so that links continue to work, and with that add a commit to this repo sign-posting the new one. Not sure if you'd given that any more thought since long ago when we first discussed it. ☺
Sounds like a plan!
Hi Sam,
After thinking about this for a while I think I'm not going to go ahead with the re-name (at least for now). I'm really sorry because I know you put a lot of work into this, in particular re-naming all the references in the book - that was a huge effort so I'm really sorry again and I hope you understand.
In the end my reasoning comes down to the fact that so far there are not actually that many people who have had explicit integration issues due to the name (over the years) - most likely this is because people are either including the project in-line in their own projects (this is somewhat how it is intended to be used) or just that not that many people are using it in production.
For the people who are having these issues I can still point them toward your fork - so thanks for that and the work there is definitely not wasted!
All together I just think the practical issues we have right now due to the name are outweighed by the messiness that doing the re-name would cause with all the other links and references across the internet that may break.
So apologies again and I hope you understand the reasoning even if you may not agree with it - and sorry I could not come to this conclusion before you dived into doing the full rename with the book. That was my bad!
Dan
Dan,
That's definitely understandable, and 100 percent your prerogative. Thank you for making such a wonderful library and for taking the time to review my PRs! I have a couple of questions though.
With the archive plan (to keep this repository, but archive it, and open a new repo with the new name (with a final commit on the old repo sign-posting the new one)), no links would break (this URL would remain alive, and functional). Is there a piece of this I am forgetting?
Alternatively, would my original proposal to make the namespace (and file names) configurable? While it's a fair bit more work (and the code isn't quite as clean in the end), it would mean that no upstream name change is needed (packagers could configure them as needed at package-time).
While I definitely understand that it is largely meant to be used drop-in, things like the pkg-config file are only useful for when used as a library for linking. So, hopefully that is not entirely out-of-scope.
I can try to keep my fork around and reasonably up-to-date for a while (both so that the rename remains an option and so that others who run into that issue will be able to have an avenue to usage), but I don't have as much bandwidth for personal projects as I used to I'm afraid.
I appreciate all your work; thank you for it!
-Sam
Hi Sam,
You're right that would not break direct links to the repo (it would just mean one more click). I meant more indirect things like references to the library in chats etc.
Making things configurable could be an option but I fear it could make the code more complex and/or break the kind of "drop these two files into your project" nature of the library.
Thanks - I can also make a copy of your fork if need be (as you've probably noticed I also don't have much time these days). To be honest I feel like this not a bad solution. It means the whole project does not need to be re-named and if anyone has namespace issues they can be pointed toward this fork which is functionally equivalent but should still work perfectly for them.
Thanks again,
Dan
Dan,
In that case, I might suggest keeping it as a branch. That way it'd be reasonably easy for you to keep it in-sync with the main one (and PRs focused on updating that branch still come here). I think that's a very reasonable solution (especially since it means that packagers can just target that branch).
All the best,
-Sam
Good idea. If I merge your PR it will just add the branch right? You didn't make any changes on master right? I can also add a note to the README about namespace conflicts pointing toward that branch.
No, the PR I opened targeted your master branch (though my work was made in a separate branch on my fork (called pcq-rename)). You can either manually pull the branch from my fork, or I could open a new PR to target a new branch for your fork. And, I think adding that note to the readme is a great idea.
Thanks - I will manually pull from your branch to a new branch on this repo and sort out the README too.
Okay should be done!
Excellent, thank you! If you would ever like to make me a contributor with only permissions to push to that branch, I can casually maintain it.
Closing this issue and the PR. ☺
Thanks again Sam - I've added you as a collaborator - don't worry I trust you not to delete everything! :)
Dan,
Happily! And thank you! And I'll make sure I don't wreck anything. ☺