Add support for the Perforce VCS client via the "p4" tool #136
Conversation
case inet:gethostname() of | ||
{ok,HostName} -> | ||
HostName ++ "-" ++ os:getenv("USER") ++ "-" ++ Basename ++ "-Rebar-automated-download" | ||
end}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please re-format init_p4_settings/1 to stay below 80 chars?
Fixed long line and improved commit message |
Thanks, can you also please add a sample p4 dep to rebar_deps:info/2 after extending the same section in rebar.config.sample? |
I'm +1 on this after the updates @Tuncer requested. |
@Tuncer: Are you talking about this part of rebar.config.sample? It doesn't currently have examples for anything except Git. And is it rebar_deps:info_help/1 where you'd like that example mirrored? |
Yes, those are the right places. If you want to add the missing examples, your patch is very welcome. Otherwise, I will complete it. |
'p4' examples added |
Works for me. cc @jaredmorrow. |
@waisbrot can you rebase this and we'll go ahead and merge it. Thanks. |
This calls the 'p4' command-line tool to checkout and sync Perforce trees. It involves significantly more special code in Rebar than using 'git p4', but it eliminates the indirection of Rebar->Git->Python->Perforce
Rebased and it looks OK to me. |
Is there anything holding up a merge? |
Perhaps the lack of interest in this pull request means that it should be rejected. If nobody else is stuck using Perforce as a VCS, why clutter up the code base? |
@jaredmorrow ping? |
I am not opposed to it, but I'd personally be more afraid of having to maintain it. @waisbrot how committed are you to this? |
@ferd I don't know what that question means. How committed are you? Maybe I'm being overly sensitive, but I find it much more discouraging for you all to kick this around in a circle while shrugging than if you just said "rejected, we don't think anyone cares about Perforce." This code works for me, for one project with one dependency inside one Perforce repository. If a bunch of people found it useful, I'd expect them to run into some problems, complain, and I'd improve it. But the vital element here is at least one person besides me who uses the patch. Anyway, since I'm not hearing anyone else care about this, I'll keep it to myself. If someone comes along in the future and wants it, they can always look at my fork for a starting-point. |
@waisbrot the question there is that I don't have perforce, I don't have any project using it, but I'm a collaborator to rebar (since a couple of weeks ago) and therefore directly or indirectly responsible for maintaining the code and fixing bugs in it. Therefore, this is a feature I know I personally cannot maintain. I am not closed to the idea of having perforce support in rebar, but we shouldn't be adding features we can't reasonably keep improving. If you say you're willing to fix bugs that may show up with this, then that's fine and it should be included. If this is a feature that is being 'dumped' on us -- sorry for the lack of better terms, I mean a pull request that is sent our way and then forgotten about by its creator -- then I am not one to want to commit to maintaining it. Does this make more sense? |
@ferd I think I was unclear and combined several unrelated statements into one blob. Let me try again (sorry about this getting a little long and dramatic): Feedback about the pull-request processI think you all do a generally excellent job of making Rebar a community project. Pull requests get dealt with quickly and the project generally feels well-loved. That's why I felt comfortable putting some significant effort into a pull request that I didn't think would necessarily get accepted. In this case, I'm guessing that everyone thought "more VCS support is better" but nobody wanted to actually push the button for a VCS that they'd never touched. That's reasonable, but in my opinion it's disheartening to be stuck in the middle spot and I'd have preferred a snap decision one way or the other. I don't think this is any systematic problem with how you're handling pull requests. Just a data-point for the future. Level of commitmentI am a little defensive about this. I think that if the time I spent writing two alternate versions of this and discussing it isn't sufficient evidence that I'd try to maintain it, then me making some kind of written promise to do so certainly shouldn't be sufficient. If you feel you have to ask, just say no. Should it be accepted? (no)You say you can't maintain it. I assume that's true of the rest of the maintainers, too. I think that's a problem for this commit because even if I swear a blood-oath to maintain it, it's just one person away from bit-rot. The other problem is that this has been hanging around for a while and I don't see anybody wanting it. I could add a 'base-64-enc-tarball-in-postgres-table' dependency type for Rebar, and even if it was awesome code the right thing to do would be to reject it because nobody will ever use that. The conclusion I've come to is that a Perforce dependency is in the same category. |
There's an additional level of zaniness that tarball in a postgres table would have that p4 doesn't (I was happy to see hg eventually making it in, so p4 would be nice for their users). I'll take a note to try and build this, check a few things, and merge it when possible. I know I'm currently in a rush at work and low on time, but I'll try to merge it in. The status for this one is: mergeable, should be merged (bar a few checks I want to make as I'll be the one to merge it in all likelihood), why wasn't it merged before (who knows). Sorry for the long wait. I think @tsloughter and myself were added to the Rebar project in an attempt to help prevent this from happening in the future, and we're trying our best. |
Add support for the Perforce VCS client via the "p4" tool
Perforce is a version control system.
This patch uses the command-line "p4" tool to fetch dependencies stored under Perforce. It's a little odder than the other VCS clients because of Perforce's notion of a "workspace" that's tracked by the P4 server.