The main motivation for this change is to make sure that higher-level
code deals with the fact that self.units.number can be None, and has
an easy way to do so.
I'm not sure all our code is *currently* doing the right thing for this
case, because I'm not sure it will ever actually come up. It's possible
that earlier Beancount plugins fill in decimal amounts for postings
that are originally loaded with self.units.number=None. I'll have to see
later whether this case comes up in reality, and then deal with it if so.
For now the safest strategy seems to be that most code should operate
when self.units.number is None.
I'm getting to ready to extend this hook to deal with income receipts as
well as expense receipts. These changes let me write the tests in a more
declarative style, so I don't have to duplicate them all again to test
credits as well as debits.
Note that we're only testing debits right now, just like the existing tests,
because the default check_type for check() is PostType.DEBIT. Part of making
the changes will be changing that to PostType.BOTH.
These were tightened up by running mypy with --disallow-any-generics
and cleaning up reported errors.
There are still a couple of cases I don't know how to deal with
right now that prevent me from setting that option permanently:
* plugin/__init__.py sets up a dict where the key is a Directive
and its value is a set of hooks that correspond to that type
of directive. The relationship between key and value is not
expressable through the type system, and any other solution would
make the code way more involved and less dynamic.
* The type variable used in _GenericRange still isn't quite right,
in the sense that specifying a value for CT creates more errors
I don't know how to deal with. Protocols seem like the right
solution for that but they apparently didn't land for Python 3.7
that I can see.
Mostly this meant giving annotations to low-value functions like
the error classes and __init_subclass__, but it's worth it for
the future strictness+documentation value.
This just returns a constant for now, but we know it may need to be
configurable in the future. Other code can start using this now
to be configurable in the future.
I wasn't too worried about this earlier because the cache mainly stores
a bunch of numbers, but there's a little more than that: the generated
URLs also include original attachment filenames, which might be sensitive
(referencing people's names, bank names, etc.). Tighten security
accordingly.
This returns a cached version of the new rtutil.RT class,
so that a single process can easily grab references to one
instance with one cache of ticket/attachment data, etc.
For now, this is basically the Python version of
ledger-tag-convert.plx. It knows how to create RT web links from
ticket and attachment IDs. It confirms that those objects actually
exist too. It may grow to encompass other functionality in the
future.
The socks package in Debian buster does a deprecated import from
the collections module. That's not directly relevant to our own
code (Conservancy has no business requirement for SOCKS support)
so ignore it.
This loads settings from the same environment variables and ~/.rtrc
file as the rt CLI.
Note that it does *not* support RTCONFIG and the config file
searching, because right now that seems like more work for more
trouble to me.
As we start reading more sensitive user configuration (like RT credentials),
this fixture makes it simpler to ensure that the tests never read the user's
real configuration, which could lead to problems like passwords in tracebacks.
