[Just] > > I don't think PackMan needs to be extensible to such an extent. Am > > I right that the current Python snippets only do version checks? > > Receipts would work just as well, provided we limit version > > checking to packages installed through PackMan. I think that's a > > reasonable constraint. [Jack] > No, receipts are specifically what I *don't* want. I want PackMan to > do actual tests of what is available. Apart from availability/version tests, we're going to _need_ receipts if we want to support uninstalls. > The problem with receipts is that it causes a package manager to live > in a completely self-centered world: it knows about everything it > installed itself and nothing else. This means that if I'm an active > developer on package X I always have to go out of my way, because the > package manager doesn't know that I've built and installed it myself. I don't follow: if you're building/installing package X yourself, why would you then want to use PackMan for package X also? I see it pretty much as an either/or situation. PackMan could still detect the availability of package X, and warn the user that it wasn't installed by PackMan itself, and therefore can't tell which version it is. With imp.find_module() this can even be done without doing an actual import -- which touches on another pet peeve of mine, see below. > I've come across this problem with Fink, SGI-inst and various other > install managers. I want to build and install Python myself, and if > someone reports a problem with package Y that depends on Python I > want to use Fink to install Y, but let Y use my copy of Python (so I > can test whether the bug has disappeared with my fix, let's assume > for the discussion). This always turns out to be difficult without > learning the internals of the package manager in question. Hm, this sounds like a reason to clearly document what PackMan does and how it works. And to keep it dead simple. PackMan is for end users. A certain amount of complexity for _developers_ seems pretty much unavoidable, and would be totally acceptable to me. I strongly feel that executing arbitrary code (even from a trusted source) is a big nono. I already have problems with doing arbitrary imports: we've seen that this can cause problems for packages/modules that have import side effects (not that _that's_ a good thing, but it isn't under our control). But we've had this discussion before, and I don't think we're likely to agree here... Just
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4