> The package you want is python3-pip (already installed?), and the
executable is /usr/bin/pip3.
Thanks Liam. Works like a champ...
--
Glenn English
On Sun, 26 Apr, 2020 at 16:13:28 -0600, ghe wrote:
> Buster, Supermicro workstation
>
> I wanted to install pip (python3 is installed and working well and my
> apt mirrors are up to date):
>
> root@sbox:~# apt install pip
> Reading package lists... Done
> Building depende
Buster, Supermicro workstation
I wanted to install pip (python3 is installed and working well and my
apt mirrors are up to date):
root@sbox:~# apt install pip
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package pip
I went to
having to activate this virtualenv every time I
> want to use those modules? or am I losing any other functionality
> provided by my system-wide python?
> I am surprised this question was asked 2 days ago, I had the exact same
> question today. The numpy module is on version 1
er functionality
provided by my system-wide python?
I am surprised this question was asked 2 days ago, I had the exact same
question today. The numpy module is on version 1.16.2 in the debian
repositories and is on version 1.18.2 in pip.
thank you,
might imagine, with other modules!
>>
>> So... do people generally use pip to maintain their python libraries,
>> rather than apt? What's the recommended best practices here?
>>
>
> I'd say the right course of actions would be to open a bug report that
> the
On Sb, 04 apr 20, 11:01:24, Alex Mestiashvili wrote:
>
> Python provides virtualenv, plus one can install most of the modules
> locally with pip3 install --user which will install the modules
> in ~/.local/lib and tools in ~/.local/bin, so don't forget to add this
> to your PATH.
At least in bus
TOUCHÉ: Also should be careful with names of python packages since
mistyping can lead to installation of malicious software and with sudo it
makes it even more fun - google for "python malicious packages"
org is at version 8.2.0, and has at least one
> recipe whose arguments are in a different order from the Debian
> packaged version (grouper, whose order of arguments changed in version
> 6.0.0). This causes problems, as you might imagine, with other modules!
>
> So... do people gen
ed on pypi.org is at version 8.2.0, and has at least one
> recipe whose arguments are in a different order from the Debian
> packaged version (grouper, whose order of arguments changed in version
> 6.0.0). This causes problems, as you might imagine, with other modules!
>
> So..
on pypi.org is at version 8.2.0, and has at least one
> recipe whose arguments are in a different order from the Debian
> packaged version (grouper, whose order of arguments changed in version
> 6.0.0). This causes problems, as you might imagine, with other modules!
>
> So... do peop
I always use pip.
From: robo...@news.nic.it on behalf of Joe Pfeiffer
Sent: Friday, April 3, 2020 11:54:31 PM
To: debian-user@lists.debian.org
Subject: python3 modules -- apt vs pip?
I've been using apt (and friends) to maintain my systems, including
p
whose arguments are in a different order from the Debian
packaged version (grouper, whose order of arguments changed in version
6.0.0). This causes problems, as you might imagine, with other modules!
So... do people generally use pip to maintain their python libraries,
rather than apt? What's the r
songbird wrote:
> Dan Ritter wrote:
> ...
> > Many of the language-specific tools have a tendency to
> > automatically acquire the latest version of a library or module
> > every time they are invoked, or to spit errors if they can't
> > pull down the version that they were asked to get. That's ra
Dan Ritter wrote:
...
> There are good reasons for doing this on a local basis.
sure, and nothing prevents that from being accomplished.
it isn't like the tools would go away.
> For example, let's say you have an organization that develops
> a software service and sells access to it. When an e
songbird wrote:
> Keith Christian wrote:
> > Are there any methods to create Debian packages for these (and
> > similar) package tools (and the files they install) so that Debian's
> > native packaging system has "inventory control" everything?
> >
> > I realize that software has been installed ou
Keith Christian wrote:
> Are there any methods to create Debian packages for these (and
> similar) package tools (and the files they install) so that Debian's
> native packaging system has "inventory control" everything?
>
> I realize that software has been installed outside of APT's purview
> sinc
Hi.
On Sat, Feb 29, 2020 at 07:46:27AM -0700, Keith Christian wrote:
> Are there any methods to create Debian packages for these (and
> similar) package tools (and the files they install) so that Debian's
> native packaging system has "inventory control" everything?
dh-make-perl, gem2deb,
Are there any methods to create Debian packages for these (and
similar) package tools (and the files they install) so that Debian's
native packaging system has "inventory control" everything?
I realize that software has been installed outside of APT's purview
since the beginnings of Debian, but I
deloptes writes:
> yes it is more or less safe - it depends how you let it install - perhaps
> there is also something under /usr/local/bin
Thanks, I'll do it then. And yes, there are 3 binaries in
/usr/local/bin from the theano package with the same installation
date, which I will also remove.
> If you mix two different package installers the consequence is that one does
> not know about the other and they can interfere with each other.
No, nothing is mixed. pip installs in /usr/local, Debian packagement
installs in /usr.
But pip3 formerly installed in /usr/local/lib/python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Dec 02, 2017 at 09:27:43AM -0600, David Wright wrote:
> On Fri 01 Dec 2017 at 12:42:35 (-0300), Eike Lantzsch wrote:
[...]
> > If you mix two different package installers the consequence is that one
> > does
> > not know about the other [..
On Fri 01 Dec 2017 at 12:42:35 (-0300), Eike Lantzsch wrote:
> On Friday, December 1, 2017 3:24:47 PM -03 Urs Thuermann wrote:
> > On a machine running Debian stretch I have installed python3, which is
> > currently python3.5. Nothing of python3.4 is present.
> >
> > But in /usr/local/lib/python3
Urs Thuermann wrote:
> Now, it seems pip3 isn't able to remove packages from that old
> directory. Is it safe to just rm -r /usr/local/lib/python3.4?
yes it is more or less safe - it depends how you let it install - perhaps
there is also something under /usr/local/bin
regards
On Friday, December 1, 2017 3:24:47 PM -03 Urs Thuermann wrote:
> On a machine running Debian stretch I have installed python3, which is
> currently python3.5. Nothing of python3.4 is present.
>
> But in /usr/local/lib/python3.4/dist-packages/ a number of packages is
> still installed. Probably,
On a machine running Debian stretch I have installed python3, which is
currently python3.5. Nothing of python3.4 is present.
But in /usr/local/lib/python3.4/dist-packages/ a number of packages is
still installed. Probably, these have been installed using pip3 when
python3.4 was current.
Now, it
Hi,
on the second try i found out that the way to avoid the need for pip
is package "python-bcrypt". I asked the wrong question to apt-file
on the first try.
Thanks to python's help("bcrypt") i can also avoid passlib:
$ python
>>> import bcrypt
added 2 MB, did not suffice, and proposed pip
apt-get install python-pip
55 MB added. Then
pip install bcrypt
Here i forgot to measure how many MB. Duh. It lasted about 3 seconds.
The "pip" run needed no superuser power.
I assume that the bcrypt algorithm is not running with python spe
28 matches
Mail list logo
