MAINT: Explicitly mention `pak` transition

[HaoZeke]

The projects at a surface level seem very similar, and maintained by the same community. From the issue tracker I believe pak [1] is the new standard (and to be integrated into devtools [2,3], which is currently where much of the remotes code [4] is derived.. It would be helpful to have this explicitly mentioned somewhere.

[1] https://github.com/r-lib/pak [2] https://github.com/r-lib/devtools [3] https://github.com/r-lib/remotes/issues/792#issuecomment-2029783081, https://github.com/r-lib/remotes/issues/794#issuecomment-2065839044, https://github.com/r-lib/devtools/issues/2572#issue-2426249675, https://github.com/r-lib/devtools/issues/2571#issue-2426249136, https://github.com/r-lib/devtools/issues/2486#issuecomment-2246438742 [4] https://github.com/r-lib/remotes?tab=readme-ov-file#remotes

[HaoZeke]

Would also be nice (but probably on the pak end) to explain why.

[J-Moravec]

While pak might be a more convenient in many cases, there is a particular user-case where I haven't found solution using it -- private bitbucket repositories.

Yes, it is a massive pain to get them working using remotes as well because Atlassian completely fails to provide decent information and even user id needs to be hunted down in one of the 10 user information menus, but the breadcrumbs exist in various remotes issues regarding bitbucket.

Specifically, remotes::install_bitbucket document the auth_user and password variables required for the authentication for the private repo. I haven't found any similar authentication information about this in the pak documentation and as expected, trying to use pak::pak(git::https...) throws 401.

My own homecooked solution (before I found out said breadcrumbs) relied on using git through the ssh, since ssh key is often expected to exist in these cases, and IMO easier to setup, but this is a bit OT.

After reading through issues, I have found two lines about authentication pointing towards gitcreds, but this IMO should be more documented.