Robert Kern wrote: >>>>setuptools-based packages can be forced to install the old-fashioned way >>>>using: >>>> >>>> setup.py install --single-version-externally-managed >>>> >>>>as long as you also specify a --root directory or a --record file. This >>>>is of course not upgradeable or uninstallable without help from a >>>>packaging tool that can utilize the results of --root or --record. >>> >>>And this particular user did not want that, either. >> >>I'm confused. They didn't want to be able to uninstall? Didn't want to >>point --record to /dev/null, or --root to /? Or something else? > > > Didn't want setuptools involved at all. He's wasted more hours on it than he > ever really wanted to in the days before non-root installs were reasonably > documented. He just doesn't trust it. He only has setuptools installed at all > because I've convinced him to distribute eggs of his project (and that I will > help him troubleshoot setuptools issues).
Setuptools and people using setuptools can only deal with actual issues, not with vague dislikes. This is open source, issues get resolved, but there's never any guarantee that issues don't *exist*. Without --single-version-externally-managed setuptools acts in ways that can be difficult to handle if .pth files don't work, or you are installing to an odd location, or something like that. It would be nice if all those issues can be documented and have useful/easy-to-resolve failure cases, and all that -- but it's not quite there yet, in part because it's not completely clear how to make all that work. *With* --single-version-externally-managed, it acts just like distutils always has. Right now one project of mine isn't using setuptools exclusively, because it still has Python 2.2 compatibility. But I see no reason to do all sorts of fiddling to support multiple installation techniques, and deal with tensions about what features can and can't be used because of multiple supported installation processes. Right now, the question should be: * Can we provide an experience similar enough to distutils to make conservative users happy? If they weren't happy with distutils, then whatever. I think --single-version-externally-managed does that. * Are we documenting this properly? That includes, are they going to be aware of the appropriate documentation at the right time in their experience. So, knowing about Python setup options before they start. Knowing about setuptools installation issues when they are using ez_setup.py. Knowing about package finding when they are using easy_install, or what they need to understand about eggs and .pth files during actual installation. * Are we providing a cohesive experience for the users who want something better than the previous status quo? Are we guiding them towards good practices? I've started using setuptools features even in packages that don't use plugins or any Egg features. A lot of these will work with distutils, but fail in weird or confusing ways (e.g., package data missing). Or I'll have to maintain an easy and an explicit way to do these things, and they'll get out of sync. I don't think it's going to be a particularly good experience for the conservative users, and it won't accomplish anything. At least when we struggle with setuptools it accomplishes something. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
