Jack Jansen wrote:
> > 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.
>
> Not for package X but for dependent packages! Think of the following
> scenario: you maintain package X, that is also in PackMan. Package Y
> depends on package X but you don't maintain it. With a know-it-all
> package manager you cannot install Y to use your X.
I don't see why not: the dependencies don't need to be "hard".
> There are now three options open to you:
> - trick the package manager to think that it installed X
> - install every package depending on X by hand
> - install two copies of X, one for your development and one
> through the package manager for use by dependent packages.
- Install package Y, getting a dialog that goes something like this:
Package Y depends on X version a.b.c. You've installed an
unknown version of Y. What would you like to do?
[Cancel] [Install X and Y a.b.c] [Install X]
In other words, it could be up to the user to decide whether to let
PackMan handle dependencies or not.
> All of this falls under my favorite annoyance #4: things that
> get in the way of developers for no obvious reason.
Well, lets improve PackMan then...
> > 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.
>
> Uhm... How about arbitrary setup.py scripts included with packages?
Isn't the whole point of PackMan to _not_ have to execute any setup.py's
to begin with? With setup.py you build a distro, PackMan does the
install without it. Am I missing something?
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