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.
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, B
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.
https://fpm.readthedocs.io/en/latest/source/virtualenv.ht
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 impu
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 able to run under a
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 the
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 alw
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 17.03.2017 18:19, Robin B
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 "
> 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,
d not
==1.7 or ==1.7.3. The same goes for the meta-packages.
On Wed, Feb 15, 2017 at 6:57 PM, Paul Moore wrote:
> Thanks for your reply, it was very helpful.
>
> On 15 February 2017 at 16:55, Freddy Rietdijk
> wrote:
> > Larger applications that have many dependencies that ar
cient to break dependency solving.
On Wed, Feb 15, 2017 at 5:14 PM, Paul Moore wrote:
> On 15 February 2017 at 15:50, Freddy Rietdijk
> wrote:
> > It's quite frustrating as a downstream having to deal with packages where
> > versions are pinned unnecessarily and therefore I
> 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
> 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
forma
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.
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, WinPython, etc?
>
My
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 is
17 matches
Mail list logo