Hey.
On Fri, Feb 17, 2023 at 3:35 PM Stefano Rivera wrote:
> There is probably some value there. You're safer from a variety of
> attacks that *could* theoretically happen on PyPI.
Well such language specific package repos (like pypi, npmjs, etc.)
have already been (numerous) times been victims
On Fri, Feb 17, 2023 at 03:17:49AM +0100, Philippe Cerfon wrote:
> But shouldn't that use case also be interesting for Debian
> Maintainers? Whenever their pip would need to download something from
> PyPI, it would mean that some dependency is likely not fulfilled in
> Debian (unless of course that
Hi Philippe (2023.02.17_02:17:49_+)
> Well in my case the main motivation was security (i.e. only using
> code) that has security support by Debian.
There is probably some value there. You're safer from a variety of
attacks that *could* theoretically happen on PyPI.
But, let me deflate Debian
On Wed, Feb 15, 2023 at 9:09 PM Stefano Rivera wrote:
> And our selection of Python modules is far from complete. It's not
> Debian's intent to provide a mirror of PyPI within Debian. Generally
> speaking, we package the modules that we find useful for supporting
> building and shipping other pyth
On Wed, Feb 15, 2023 at 5:35 PM Stefano Rivera wrote:
> You sure it isn't doing an isolated build? Try --no-build-isolation.
I absolutely am not :D (I'm really not a Python expert... or about
it's various build systems, pip, etc.).
And that seems to have done the trick.
And it further seems that
On 2023-02-16 01:12:49 + (+), Ian Norton wrote:
> I agree that is "easiest" but what I was after was the ability to
> restrict myself to the curated and signed packages from debian,
> pypi is just as bad as old CPAN when it comes to packages
> disappearing or being broken or depending on to
On Thu, Feb 16, 2023 at 01:12:49AM +, Ian Norton wrote:
> I agree that is "easiest" but what I was after was the ability to restrict
> myself to the curated and signed packages from debian, pypi is just as bad
> as old CPAN when it comes to packages disappearing or being broken or
> depending o
I agree that is "easiest" but what I was after was the ability to restrict
myself to the curated and signed packages from debian, pypi is just as bad
as old CPAN when it comes to packages disappearing or being broken or
depending on totally random versions
On Wed, 15 Feb 2023, 22:01 Jeremy Stanley
As someone who does Python software development on Debian constantly
for their $dayjob, my best advice is to just install things from
PyPI into and run them from venvs/virtualenvs. The default "--user"
install mode pip offers is fragile and leaves you with potential
conflicts anyway if you need dif
Hi Ian (2023.02.15_18:07:39_+)
> My suggestion to the pip folks was a plugin system and extension point for
> "install x" package that distros could provide implementations for
Yeah, something like that could work. I don't know how useful it would
be, though.
Obviously, only root could use it
My suggestion to the pip folks was a plugin system and extension point for
"install x" package that distros could provide implementations for
On Wed, 15 Feb 2023, 16:35 Stefano Rivera, wrote:
> Hi Philippe (2023.02.13_01:11:28_+)
> > On Sun, Feb 12, 2023 at 7:31 PM Donald Stufft wrote:
> >
Hi Philippe (2023.02.13_01:11:28_+)
> On Sun, Feb 12, 2023 at 7:31 PM Donald Stufft wrote:
> >
> > I'm pretty sure that most if not all debian packages already ship
> > the required information for pip to see them as installed, and if
> > they are installed and they satisfy the dependency cons
Hey.
On Sun, Feb 12, 2023 at 7:31 PM Donald Stufft wrote:
>
> I'm pretty sure that most if not all debian packages already ship the
> required information for pip to see them as installed, and if they are
> installed and they satisfy the dependency constraints that pip has for those
> project
On Sun, Feb 12, 2023 at 9:05 AM Ian Norton wrote:
> I requested this kind of thing from the pip folks as
> https://github.com/pypa/pip/issues/11644 and others have requested
> similar, such as https://github.com/pypa/pip/issues/11607
While they wrote it would be discussed, it doesn't really seem
I'm pretty sure that most if not all debian packages already ship the required
information for pip to see them as installed, and if they are installed and
they satisfy the dependency constraints that pip has for those projects, then
they'll be used.
The question of having pip automatically inst
An example using alpine (it seems some packages sporadically include
the dist-info folders): There is some more recent info here
https://peps.python.org/pep-0627/
/ # apk add py3-pip
(1/6) Installing py3-six (1.16.0-r3)
(2/6) Installing py3-retrying (1.3.3-r3)
(3/6) Installing py3-parsing (3.0.9-
https://packaging.python.org/en/latest/specifications/recording-installed-packages/
defines the python spec where a package such as pyparsing would create
a tree of files under:
site-packages/pyparsing-3.0.9-dist-info/ including RECORD which is
essentially a sha256-based manifest of files and some
You've made me wonder if it would be feasible to have a debian-centric
tool that populates .dist-info from debs?
On Sun, 12 Feb 2023 at 08:05, Ian Norton wrote:
>
> I requested this kind of thing from the pip folks as
> https://github.com/pypa/pip/issues/11644 and others have requested
> similar,
I requested this kind of thing from the pip folks as
https://github.com/pypa/pip/issues/11644 and others have requested
similar, such as https://github.com/pypa/pip/issues/11607
On Sun, 12 Feb 2023 at 04:56, Philippe Cerfon wrote:
>
> Hey.
>
> I hope this is not too off topic.
>
> As far as I und
Hey.
I hope this is not too off topic.
As far as I understand, dh-python, when building packages somehow
automatically uses the Debian package names and even prevents e.g.
setuptools from downloading any dependencies by setting a (hopefully
not running) proxy.
I wondered whether it's possible t
20 matches
Mail list logo
