[Distutils] Re: [poposal for preparing a pep] sharing package installations between virtualenvs

What Conda and Nix do is basically having a store with packages, and then indeed linking them to form environments. While this works, it is important that one is very careful tracing how the packages are built, because not doing so can easily cause trouble in case of modules with extension types.

[Distutils] Re: Should an sdist/MANIFEST.in include docs and tests?

As a Nixpkgs Python maintainer I often ask projects to include their tests in the sdist so we can run them when packaging. I prefer it also when an sdist basically represents a snapshot of a repository. On Mon, Sep 10, 2018 at 8:08 AM, Thomas Kluyver wrote: > On Mon, Sep 10, 2018, at 12:33 AM,

[Distutils] Re: Packaging Advice for EFF's Certbot

I think administrators should only install native packages, and thus I recommend having a solution that can build native packages. Consider FPM, a tool for creating native packages. It can create native packages from virtualenv environments.

Re: [Distutils] [proposal] shared distribution installations

Hi Ronny, What you describe here is, as you know, basically what the Nix package manager does. You could create something similar specifically for Python, like e.g. `ied` is for Node [2], or Spack, which is written in Python. But then how are you going to deal with other system libraries, and

Re: [Distutils] PEP 517: Python 3 finder?

I'm wondering about this one as well. Even when it is not a different interpreter version it could also be a different environment. Who "owns" environment variables like PYTHONHOME and PYTHONPATH? On Fri, Jun 16, 2017 at 9:13 PM, Daniel Holth wrote: > Build systems should be

Re: [Distutils] Introducing PyPIContents

This looks very nice. The readme states that monkeypatching is used to extract this info from the `setup()` call. Is `setup.cfg` also taken into account? What would it take to split of this part into a separate module/package so that we have one function taking a source directory and returning

Re: [Distutils] reproducible builds

As Thomas mentioned PYTHONHASHSEED is sufficient to solve non-determinism by the hashing. In my experience this hashing, along with datetimes (e.g. in the bytecode) are typically the only causes of non-determinism in Python packages. Someone from I think Debian did mention [1] that they cannot

Re: [Distutils] reproducible builds

Nixpkgs [1] uses SOURCE_DATE_EPOCH as well. We can reproducibly build the Python interpreter (and packages with [2]). [1] https://github.com/NixOS/nixpkgs [2] https://bitbucket.org/pypa/wheel/pull-requests/77 On Fri, Mar 17, 2017 at 6:46 PM, Matthias Klose wrote: > On

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

Users may want to split installations over multiple folders and creating a working environment by merging them (through symlinks / PYTHONPATH / sys.path / site / .pth). Python doesn't support multiple versions of the same module during runtime, and therefore I don't see any benefit in including a

Re: [Distutils] distlib and wheel metadata

> Here's an example I've just run into that involves a == dependency on a public package: I have a library that needs to access some C API calls on Windows, but not on other platforms. The natural way to do this is to split out the CFFI code into its own package, _mylib_windows_helper or whatever,

Re: [Distutils] distlib and wheel metadata

or ==1.7.3. The same goes for the meta-packages. On Wed, Feb 15, 2017 at 6:57 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > Thanks for your reply, it was very helpful. > > On 15 February 2017 at 16:55, Freddy Rietdijk <freddyrietd...@fridh.nl> > wrote: > > Larger applicatio

Re: [Distutils] distlib and wheel metadata

17 at 5:14 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 15 February 2017 at 15:50, Freddy Rietdijk <freddyrietd...@fridh.nl> > wrote: > > It's quite frustrating as a downstream having to deal with packages where > > versions are pinned unnecessarily and therefore I'v

Re: [Distutils] distlib and wheel metadata

> Maybe it would help if you have a concrete example of a scenario where they would benefit from having this distinction? In the Nix package manager (source distribution with binary substitutes) and Nixpkgs package set we typically require the filename and hash of a package. In our expressions we

Re: [Distutils] Maintaining a curated set of Python packages

> Theoretically we could allow people to not just select packages, but also package specifiers for their “curated package set”, so instead of saying “requests”, you could say “requests~=2.12” or “requests==2.12.2”. If we really wanted to get slick we could even provide a requirements.txt file

Re: [Distutils] Maintaining a curated set of Python packages

It's interesting to read about how other distributions upgrade their package sets. In Nixpkgs most packages are updated manually. Some frameworks/languages provide their dependencies declarative, in which case it becomes 'straightforward' to include whole package sets, like in the case of Haskell.

Re: [Distutils] Maintaining a curated set of Python packages

On Fri, Dec 2, 2016 at 4:33 PM, Robert T. McGibbon wrote: > Isn't this issue already solved by (and the raison d'être of) the multiple > third-party Python redistributors, like the various OS package maintainers, > Continuum's Anaconda, Enthought Canopy, ActiveState Python,

[Distutils] Maintaining a curated set of Python packages

Hi, I would like to propose that, as a community, we jointly maintain a curated set of Python packages that are known to work together. These packages would receive security updates for some time and every couple of months a new major release of the curated set comes available. The idea of this