Being all things to everyone is tough. I recently contributed some code to support the openSUSE package manager, zypper, in pybombs. So universal support is kind of an evolving feature. Perhaps it would be a start to simply limit the initial virtualenv support to python2. I would suggest that if one were in a virtualenv, you let that handle the pip version (which should be referenced just by the pip command). I would also submit that python packages should not be added to the system via a package manager if you're in a virtualenv. This would alleviate some of the package naming discrepancies between the versions. I don't think gr-recipes supports python3 packages right now for any packager. Good points nonetheless.
Jared. On Fri, Mar 31, 2017 at 10:30 AM, Martin Braun <martin.br...@ettus.com> wrote: > Please note that there's an open issue on how PyBOMBS and venvs are > effectively broken (https://github.com/gnuradio/pybombs/issues/363). > There are also related issues regarding the fact that we don't know if > we're running Python 2 or 3. So yeah, I know about this, and would love > to see it fixed, but I'm not doing it myself anytime soon. > > For example, what if your system's default is Python 2, but your > virtualenv is running Python 3. In that case, you would need to make > sure that you don't accidentally check your system's package manager for > python2-mako. pybombs itself may be running a different Python than is > going to be executed in the prefix. > The same holds for if we need pip, pip2, or pip3. > > I'm open for suggestions and pull requests, but keep in mind that I > can't merge stuff if > > - It's based on personal preferences, e.g. the pip vs. apt discussion. > Note that there's also different cases here, you might prefer apt over > pip for system-wide installs, and pip over apt for your virtualenv install. > - It hardcodes stuff where it shouldn't (e.g., having IF PKGR == PIP > style code in the package_manager.py) > - It makes assumptions about people's systems. > > Also, I should acknowledge that both Jared and Marcus have contributed > to PyBOMBS, so this is not just an empty discussion here :) > > Cheers, > Martin > > On 03/27/2017 08:14 PM, U L wrote: > > This is a problem I have faced as well. I have a number of projects at > > various levels of modification of GR and various 3rd party python > > packages being supported. I find having virtualenvs to be very useful > > in keeping python package versions, GR mods, and my own modules in > > agreement. I've been tinkering a bunch with getting venvs and pybombs > > to work together and I think I've made some headway. For example, the > > elevated privileges for pip is (nominally) hardcoded in > > packagers/pip.py. I made a modification to condition elevation on the > > presence of a virtualenv, which is detected in the config_manager. This > > is one way to perhaps get pybombs and virtualenvs to play nice. I'll > > hopefully be offering a pull request soon that incorporates a number of > > changes. > > > > On Wed, Mar 22, 2017 at 12:30 PM, Naceur <naceur.elo...@nist.gov > > <mailto:naceur.elo...@nist.gov>> wrote: > > > > You are right if they had access to it at first place. Anyhow I > > fixed it. > > > > > > > > -- > > View this message in context: > > http://gnuradio.4.n7.nabble.com/installing-a-python- > package-without-elevated-privileges-tp63183p63258.html > > <http://gnuradio.4.n7.nabble.com/installing-a-python- > package-without-elevated-privileges-tp63183p63258.html> > > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
