And another thing is that to support multi-installation with differents versions/packages for projects on the same machine. If you just have a "global" system installation as a base, it is a problem. You must have a way to hook to use your software and you must have means to make multi-installations side by side isolated from each other.
kiorky a écrit : > Python installers/package managers are not there to install system > dependencies. > > For me, it s totally out of scope and can lead to security holes. > Eg, you include a lib "a" (dynamic or static), and it has a hole, to fix it, > you > must re-release you egg and the users must reinstall it on their side. > > But if you use the system provided "library", no matter that it was provided > by > the host system or an isolation software like minitage: > If you choose to use dynamic linking when building the egg: > * You must only rebuild the library, all is dynamic. > > If you choose to use static linking when building the egg: > * You must rebuild the implied egg too and in the meantime you are > exposed to > the security hole. > > Another reasons not to include system dependencies in the python dependencies > expressions is that the system dependencies are: > - To use the system package manager, you must have great privileges > - Installation is not portable, there is plenty of package managers > outside > - Even if you have support for the underlying package manager, the user > may > want not to use the system sofware but a custom version of the library built > somewhere. And it will be a PÏTA and for the metadata parser to have the > knowlegde about it. > > static is not a solution, even not an option for me except in very rare > particular cases like having the binutils (/bin/ls, /bin/mount ...) static for > recover puposes... > > Sridhar Ratnakumar a écrit : >> On Wed, 30 Sep 2009 13:58:56 -0700, Ian Bicking <[email protected]> >> wrote: >> >>> The other option could be to enable support for static linking so as >>> to make the egg a reasonably self-sufficient binary (eg: lxml's >>> --static flag to setup.py) >>> Just to throw more in the mix -- this option is totally ad hoc in >>> lxml, which means it's hard to handle in an installer like >>> easy_install or pip. That is, there's no good way to do "easy_install >>> --static lxml" (it's more possible in pip, but still quite awkward). >> Maybe we can standardize the ``--static`` flag for setup.py and >> installers? The benefit of this is that builders and installers can >> support a static build feature without having to hack build scripts for >> specific packages (Currently PyPM's backend maintains custom code for >> building such special packages). >> >> Examples of usage:: >> >> $ python setup.py build --static install >> $ easy_install --static lxml >> $ pip install --install-option="--static" pip >> >> -srid >> _______________________________________________ >> Distutils-SIG maillist - [email protected] >> http://mail.python.org/mailman/listinfo/distutils-sig > > > ------------------------------------------------------------------------ > > _______________________________________________ > Distutils-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
