Some Code I Deleted
blog.afoolishmanifesto.com
blog.afoolishmanifesto.com
That bug makes me sad. It was opened in 2011. It's a trivial bug to fix. Two separate fixes were submitted, one with several iterations addressing all feedback. By my count, at least five people have dealt directly with the issue (contributing or reviewing code, providing feedback, etc). Who knows how many folks have been affected by the bug and found a work-around or gave up on it. Meanwhile, a fix ends up just withering on the vine for years.
This is not a complaint specific to Python. I've seen it happen with many projects, both closed and open. What a waste of people's time.
Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat.
A new patch then came in in April 2016 which has been completely ignored.
I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it.
It still seems like a huge waste of time though.
But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.
In general, there are different reasons, depending on the project size, and of course the maintainers' personality.
On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times.
In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely.
On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity.
Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort.
Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.
I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game.
All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.
I don't know what the solution is, and it is probably just an inherit flaw with volunteer-run open source projects. Without someone being paid to get the bug count down it's easy for bugs like this to get forgotten about.
This, of course, does not work with core libraries on which many other standard libraries depend. But its not the case with netrc.
You make the machine unique and use the account field to identify the real host.
Not a solution for all purposes but for code you're writing yourself it is fine.
I use this technique in a Python program which hits REST apis on the same endpoint but under different usernames / privileges / credentials.
You can also put things like ssh key, saml, encrypted passwords etc into account and have a fake password for slightly better security. I've seen a proposal for a better netrc format (e.g. integrated with gpg) but I can't find it right now.
PS. about the only documentation you'll find on most machines for netrc is the Perl Net::Netrc manual page.
In my experience, you sometimes need to write code in order to realize that you didn't need to write it in the first place. Maybe that's one of the things that separates a senior developer: they know what code not to write.
I use it quite sparingly. At work, sometimes I need to make a large number of calls to a password-authenticated API. My approach there is to `sudo mount -t tmpfs -o size=5M tmpfs ~/tmp/secret/`, put a .netrc in there, and use curl's `--netrc-file` option to point to it. When I'm done, I umount the ramdisk. The password never hits the disk unencrypted, modulo swap.
Something like this should work:
#!/bin/bash
password=$(...) # replace with code to extract password from the the password manager
generate_netrc()
{
printf 'machine www.example.org login foo password "%s"\n' "$password"
}
curl -v --netrc-file <(generate_netrc) http://www.example.org
The man page for netrc on most Unix or Unix-like systems that I checked includes this for how the "machine" token is handled:
> Identify a remote machine name. The auto-login process searches the .netrc file for a machine token that matches the remote machine specified on the ftp command line or as an open command argument. Once a match is made, the subsequent .netrc tokens are processed, stopping when the end of file is reached or another machine or a default token is encountered
That specifically talks about ftp's use of .netrc, and as described only the first entry for a host is ever processed.
I can think of two ways to take that, from the point of view of a programmer thinking of using .netrc for a program that is not ftp.
1. .netrc was designed for ftp. If I'm going to use another programs' file I should use it exactly like it is documented to use it...so I should only look at the first matching machine too.
2. .netrc was designed for ftp, but it is explicitly documented as only looking at the first matching machine. What that tells me is that I can go ahead and tell my users to use .netrc for my program too, and if they need different credentials for my service than they do for ftp on a given machine, go ahead and make a separate machine entry for my program. Just make sure it is not the FIRST machine entry for that machine. I can add some way for them to tell my program which entry to use when there are multiple machine entries that match. Either a command line argument, an environment variable, or since ftp is guaranteed to not process other than the first match I could even add a new token in .netrc that marks my entry.