wiki:WhyIHateX

Version 1 (modified by Brian Warner, 13 years ago) (diff)

gather my frustrations in one place, for easier reference

This is a collection of things that have annoyed me. I'm writing them down so they'll seem smaller: if I only keep track of them in my head, I'm sure that I've forgotten a few, and thus the perceived list is usually larger than the actual list.

windows

  • I had to use less-readable pathnames for flogfiles and incident reports (#177). Instead of incident-2011-06-05--14:40:21Z-w2qn32q.flog, I had to switch to incident-2011-06-05--14-40-21Z-w2qn32q.flog. The colons are more readable, and work fine on everything except for windows, but the hyphens are safe on all platforms. I'm bowing to the desires of my colleagues to value uniformity over readability.
  • the normal safe atomic-rename trick (for overwriting a file) doesn't work on windows.

setuptools

  • I added code to setup.py to add "entry points", which I dislike, because their use of pkg_resources makes it hard to locate the actual code being imported, and because they introduce a build step that isn't normally necessary. The sys.path-appending preamble in e.g. bin/flogtool works fine on all but windows, I think. (#109)
  • I also added code to setup.py to add "install_requires", to present dependency information in a setuptools-visible way. While not a direct drawback, in my experience this dependency information is more likely to cause spurious failures at runtime than to improve anything. (when a dependent package is perfectly usable but, for some dumb reason, lacks version information that setuptools can recognize, then the pkg_resources checks in entry-point scripts will refuse to even attempt the import).
  • Using setuptools at all means that 'setup.py install' doesn't work like GNU Autoconf -style 'make install', which causes problems with stow, and with debian package-building scripts. You can use the unpleasantly verbose --single-version-externally-managed flag to get closer to the original, if you can remember or discover it. I feel that OS-level packaging systems are better than per-language packaging systems, so I'd rather setup.py be simple and higher-level tools get more control.