Hey,
> I have heard folks in the Guix maintenance sphere claim that we never rewrite
> git history in Guix, as a matter of policy. I believe we should revisit that
> policy (is it actually written anywhere?) with an eye towards possible
> exceptions, and develop a mechanism for securely
Hi,
> I'm planning on refreshing Guix's haskell packages as my fix for
> https://issues.guix.gnu.org/66347 requires rebuilding all of them
> anyway. Should I try to keep commits small with only one update per
> commit (which is more work but managable if I don't care about the
> commits being
Hi,
> […] or is it just a matter of successfully building all dependents that you
> are introducing against master?
basically this and running the system tests.
Lars
Hi,
> What is the cadence for merging the python-team branch into master?
> Should you do it, me, or someone else?
there’s no timeline or schedule. It happens when someone does the
integration and testing work. I don’t have the time to do this right
now, so please go ahead.
Note there’s also
Hi,
> What is the git approach for keeping the Python branch up to date? 閭
> Should I be rebasing off of master or something else?
yeah, that’s generally what I would do before working on it. Note that
you cannot force-push into Savannah. You have to remove the remote branch
and create it again.
Hi Andy,
> curious poetry is not named python-poetry in Guix as following
> convention of most python packages
packages providing a binary instead of a library usually skip the
language-specific prefix, because the programming language does
not matter in that case.
Lars
Hi Reza,
> Poetry is not building on ci.guix.gnu.org [1]. There is a pending patch
> [2] on the issue tracker. What is missing to apply this patch and how
> can I help?
both contributors to that issue – John and me – are busy with other
things right now. That’s all.
My proposal in the
Hi,
> a less frequent drop in substitute availability on master would considerably
> elevate my satisfaction with guix as a user. and in my reading that is the
> cost that Christopher talks about here.
I was also unhappy enough to pull after the change was made, but
substitutes were not
Hi,
> Everything looks great, except that GHC failed to build from source
> locally. (I know GHC bootstraps separately.) I don't think my code
> caused the failure, but it's possible. Looks like it failed in the
> tests.
could you share your changes? The logs are rather unhelpful.
Cheers,
Lars
Hi Andreas,
> I wanted to set up automatic building on cuirass for the Python updates
> branch, but was not sure which one it is:
> $ git branch -a | grep python
> remotes/origin/python-updates
> remotes/origin/wip-python-graphviz
> remotes/origin/wip-python-mne
>
Hi,
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed
> (error == NULL): Failed to load
> /gnu/store/vkcl29s7qcfgqz1cs6lab98fyxsxyczx-adwaita-icon-theme-43/share/icons/Adwaita/48x48/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Hi Andreas,
> Probably so! I will let you decide whether to apply it or to drop the 9.0
> version, both are fine from the core-updates point of view.
I fixed 9.0 in commit dc9c09023a5258de035424169b8e804acfd38cb2, but 9.4
still fails :( Will investigate.
Lars
Hi Andreas,
> Well, I would see this as rather an action for a later feature branch.
> Except for removing 9.0 by building 9.4 with 9.2, since 9.0 does not
> build now anyway.
shouldn’t this snippet from 8.10 also work for 9.0?
(modules '((guix build utils)))
(snippet
Hi Simon,
> and instead we could try this shorter one:
>
>7.8.4
> -> 8.0.2 (needs >= 7.10)
> -> 8.4.4 (needs >= 8.0)
> -> 8.8.4 (needs >= 8.4)
> -> 9.2.5 (needs >= 8.6)
>
> WDYT? If no objection, I will give a try.
note that the information on haskell.org is not always accurate and thus
Hi Andreas,
> This also did not work - timeout after 3600 seconds of silence,
> the property is overwritten by the guix daemon, I think.
> Anyway, as said before, I rather think this is a real problem with
> the tests (maybe depending on some special situation on berlin if you
> could build it on
Hi Simon,
> Thanks for checking. It also builds for me locally. So I guess,
>
> +(properties
> + ;; 3 hours to avoid time-out in the check phase.
> + `((max-silent-time . 10800)))
>
> would be helpful. And it should be inherited by 9.2.5 so it should
> also build on CI. WDYT?
Hi Simon,
> About GHC, I am trying to build ghc-8.10.7 on core-updates for i686. It
> could be nice to fix it. Well, I will be happy if someone™ beats me. ;-)
GHC 8.10.7 on i686 built fine for me locally with all timeouts
disabled. 9.2.5 is not done yet, but is slowly processing through the
Hi Andreas,
> I have just fixed calibre. It failed to build because .sip fails are
> now in a subdirectory /lib/python3.10/site-packages/PyQt5/bindings
> instead of /share/sip (or maybe before, they were in both directories).
no, it was definitely in /share/sip before, but the pyproject-based
Hi again,
> I just updated python-ipython to the first version that passes all tests
> without any change, in the hope that this would have the least impact on
> its dependents. Without luck, now python-trio fails. Updating this to the
> latest version 0.22 does not help. I copy-paste the error
Hello Andreas,
> I looked at it and it seems that python-sip and python-pyqt-builder need a
> version bump and we should maybe switch to pyproject-build-system. However
> python-sip does not expose any switches to specify a different path for
> .sip file includes. That requires custom patches for
Hi,
> Well, there is pyqt as written elsewhere, but this is not only python.
I looked at it and it seems that python-sip and python-pyqt-builder need a
version bump and we should maybe switch to pyproject-build-system. However
python-sip does not expose any switches to specify a different path
Hello Andreas,
> excellent! It contradicts the feedparser author's statement that everything
> works well, so if you have the courage, maybe you could report the issue
> upstream.
I just saw it was fixed on the develop branch already, but there’s no
new release:
Hi again,
> > > Right now I am left with a number of test failures that look real and
> > > cannot
> > > easily be solved by an upgrade (either because we are already on the
> > > latest
> > > version or because the tests still fail): python-sgmllib3k,
> > > python-typeguard
> > > and
Hello Andreas,
> This one is used for python-feedparser, used for calibre and quodlibet.
> The feedparser author is not enclined to work on it:
>https://github.com/kurtmckee/feedparser/issues/328
> I would suggest to try compiling python-sgmllib3k (and potentially
> python-feedparser) without
Hi Andreas,
> But I confirm that ghc@9.2.5 now fails its tests, it has happened a second
> time for me. Nothing in the recent commits to core-updates since I tried
> the last time springs to mind as obviously having a connection to these
> failures.
fixed by commit
Hello Andreas,
> Maybe you had a transient test failure? "async" sounds like the kind of
> tests that could fail randomly...
unfortunately it is not a transient failure. I can reproduce it every
time I try to build python2 on core-updates, even with `--cores=1`.
And it also reproduces on master.
Hello Andreas,
> the latest trial to compile ghc@9.2.5 resulted in many test errors,
> see below.
I tried to compile GHC on core-updates recently, but didn’t even get
to GHC 9.2.5, because python2 failed to build (test test_asyncore failed,
without any further information). Do you have any extra
Hello Felix,
> I see build failures [1] for Ghc 9.2.5 in the Cuirass job set [2] for
> my own feature branch. [3] They are caused by a one-hour timeout. Did
> you folks figure out how to extend the timeout limit on Cuirass when
> working on your own branch? Thanks!
I don’t see GHC being rebuild
Hi,
> I updated it to its latest version under its current name python-cheetah,
> but would suggest to rename it to python-ct3. What do you think?
I don’t think we should follow PyPi’s names strictly. python-cheetah3
makes much more sense than python-ct3. That’s what upstream-name is for.
Lars
Hi,
> Do we have a list of packages in the python importer that can be removed
> from inputs? Like already exists for hackage (and maybe others)?
I’m not aware of any list like that and to compile it we’d probably
have to build all python-* packages and check whether any of their
installed
Hi,
> > the branch has been merged into master.
> \o/ Nice, thank you!
well, GHC fails a single testcase on i686 (which we did not test for
wip-haskell) right now[1], but it’ll take some rounds of building it
locally until I have this sorted out too.
Lars
[1]
Hi,
> just a heads-up: The long overdue Haskell update is finally rolling in,
> bumping our packages to Stackage release 20.5 and the compiler to 9.2. The
> corresponding issue is #61420.
the branch has been merged into master.
Lars
Hi,
> Right now I am left with a number of test failures that look real and cannot
> easily be solved by an upgrade (either because we are already on the latest
> version or because the tests still fail): python-sgmllib3k, python-typeguard
> and python-coveralls. See messages below.
I don’t know
Hi Andreas,
> This version requires python-importlib-metadata; not its latest version 6,
> but something at least 5 and less than 6. We were still at 4.something.
> So I have just updated it to 5.2.0, the latest version 5 from last December.
> This gives me python-json-spec, so I am one step
Hi Andreas,
sorry, I can’t quite keep up with the Python issues on core-updates
right now :(
> Yet another python failure: python-pathlib
this is a backport of Python’s built-in pathlib library. It should be
dropped as a dependency for all of these packages, since our Python is >=
3.4 – the
Hi,
> Except that we have to decide what to do about its dependents...
upgrade or drop if not possible. pycryptodome does not provide an entirely
compatible interface (see https://www.pycryptodome.org/src/vs_pycrypto),
so we cannot simply switch existing packages from pycrypto to pycryptdome
Hi Andreas,
> *** File
> "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1/lib/python3.10/site-packages/Crypto/Util/number.py",
> line 139
> value |= 2L ** (N-1)# Ensure high bit is set
> ^
> SyntaxError: invalid decimal literal
> error: in
Hi Andreas,
> I do not think we should coordinate, this was part of the motivation for
> considering feature branches in the first place, to avoid entanglement
> with different updates.
ah, alright. I’ll give everyone more time for reviews and then just
merge it.
> However, QA has not run yet:
>
Hi,
just a heads-up: The long overdue Haskell update is finally rolling in,
bumping our packages to Stackage release 20.5 and the compiler to 9.2. The
corresponding issue is #61420.
Is there anything preventing a merge into currently? Can we coordinate
the merge with some other big
Hi,
> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing? :-) No rush,
> though the sooner the more likely we are to get an answer.
I’m also fine with the terms proposed here.
Lars
Hi Ludo,
> Please take a look and send patches if needed! If someone can come up
> with some kind of a logo for the Guix Days, that’d be great; otherwise
> we’ll just reuse the one from last year.
note that the Guix Days take place on February *2nd and 3rd* (correctly
identified as Thursday and
Hi jgart,
> Hi, what's the status on packaging GHC >= 9.0?
> Is anyone working on that?
there is commit 7a9350c208be14484d4fa6d90c0169f40fcf500e on wip-haskell,
which adds GHC 9.0.2. No further work has been done to update the Haskell
ecosystem. Help is welcome though, because it’s very
Hi Maxim,
> commit 6a2e303d3a49baf7c222a70b91f453e9efd456c6
> Author: Maxim Cournoyer
> AuthorDate: Wed Oct 5 21:48:25 2022 -0400
>
> guix-install.sh: Improve prompt_yes_no procedure.
>
> * etc/guix-install.sh (_flush): New function.
> (prompt_yes_no): Clear input, then only
Hi Mathieu,
> 1. Defining your team scope, if you are already part of a team
I pushed scopes for the Haskell and Python teams, but especially for the
latter packages are all over the place and barely covered by file-based
scopes unfortunately.
Cheers,
Lars
Hi Mathieu,
> I noticed that while the "samba" test
> works fine on my machine, it fails on the CI:
> https://ci.guix.gnu.org/build/1495525/log/raw
> any idea why?
it works on my machine too. The log above says
---snip---
This is the GNU system. Welcome.
komputilo login: In execvp of
Hi Marius,
> I expect many Python packages need to be updated for 3.10. To ease this
> process it would be great to get the revamped build system from
> 'wip-python-pep517' merged. I plan to look at it "soon", but volunteers
> welcome. :-)
not to discourage you from taking a look, but
Hi zimoun,
> Maybe it could be better to move the ’cabal-revision’ from the
> ’arguments’ field to the ’origin’ field.
> Perhaps, we could have a ’cabal-revision’ procedure returning a G-exp
> and put it under the ’snippet’ field.
> WDYT?
it would be awesome to have that functionality and I agree
Hi zimoun,
> Is it a manual in-place replacement? Or is it an automatic in-place
> update by Hackage infrastructure? Or do I miss a point?
>
> In all cases, these revised Cabal files are not archived elsewhere than
> in Hackage, right? The question is thus, where could we archive them?
>
>
Hi,
> Thanks :-) Keeps the PRs away, or at least you can't prove
> otherwise.
you could also enable “temporary interaction limits”[1] in your org
account, which applies to all of its repositories. It’s only valid up
to 6 months, but maybe better than nothing…?
Cheers,
Lars
[1]
Hello Andrew,
> The Guix Maintainer Collective (tm) would like to welcome Andrew Tropin,
> aka abcdw, as our newest committer! I'm sure many of you recognize them
> from their work on Guix Home and their regular videos hacking on Guix,
> among other things.
welcome! Good to have you here as a
Hi,
> It should, but sometimes there are bugs in the package definition or
> build system, in this case causing python-rdflib to refer to the
> native-input python-pytest. Likely it's the 'add-install-to-path' phase
> adding too much, a known issue, which could be solved by separating
>
Hi,
> Sounds good, thanks for the fix!
d921516f50a946e92f9d5dc6d3bd49aca9788ac2 services: greetd: Remove unnecessary
user groups.
Cheers,
Lars
Hi,
> Since greetd is currently being run as root, it doesn't need any
> extra group membership.
indeed, agreety works fine with that patch. I’d still keep the video
supplementary group, so one can run gtkgreet/wlgreet (if they ever pop
up in Guix). Any objections?
Cheers,
Lars
Hi,
> Only root can write to /var/log, so wheel is irrelevant. And, indeed, greetd
> logs are being written as root:
oh, I guess they are written by greetd, not the greeter itself. Does
greetd work without the groups in questions? (I don’t have access to
a powerful machine right now to test it.)
Hi,
I merged greetd.
> (group "wheel")
> (supplementary-groups '("users" "tty" "input" "video"
> "audio"))
> […]
> I can understand the need for tty and input, but why does the
> greeter user need the wheel and audio?
I believe wheel is necessary to write logs to /var/log,
Hi jgart,
> validating 'flake8'
> /gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages
> ...checking requirements: ERROR: flake8==3.9.2
> ContextualVersionConflict(pyflakes 2.4.0
>
Hi Ricardo,
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
* Python Team
Lars-Dominik Braun
* Haskell Team
Lars-Dominik Braun
Anyone interested to join these with me
Hi jgart,
> ==
> FAIL: test_search_submodule (ropetest.contrib.autoimporttest.AutoImportTest)
> --
> Traceback (most recent call last):
> File
>
Hi zimoun,
> In the light of «‘staging’ branch is open!» [1], it could be nice! :-)
there’s no way we’ll get this done by your proposed date May 8th. Last
time it took me two weeks full time to update everything. I don’t want
to delay the merge of staging for this.
> About the importer, I do not
Hi everyone,
it’s time to update our Haskell environment – again. GHC 9.0 has been
out for a while and Stackage updated its LTS distribution to version 19
recently, providing a new set of packages for GHC 9.0.
Additionally there some issues/patches regarding haskell-build-system
and the
Hi Chris,
> The Fedora document explains that at least the hosts cache will be
> handled by systemd-resolved. Can I expect Guix-built programs to "try
> to use systemd" when resolving host names, or is additional
> configuration likely to be required?
as far as I know systemd also plugs into the
Hi Guix,
and a warm welcome to Efraim!
Maybe update the about part of the website too? (See attached patch.)
Cheers,
Lars
diff --git a/website/apps/base/templates/about.scm b/website/apps/base/templates/about.scm
index 427b908..3d72adf 100644
--- a/website/apps/base/templates/about.scm
+++
Hi,
> I just wanted to mention that python-sqlalchemy-utils sanity-check phase
> is broken.
> […]
> ImportError: cannot import name '_literal_as_text' from
> 'sqlalchemy.sql.expression'
>
Hi Ricardo,
> FWIW, mumi also lets you search patches as all contents are indexed:
>
> https://issues.guix.gnu.org/search?query=%22%28gnu+packages+python-web%29%22+is%3Aopen+tag%3Apatch
thanks, I didn’t think about that. I tried searching
for python-build-system, but not all patches –
Hi Maxim,
> I've grown to like our apparent lack of structure; we interact globally
> on any topic of interest and the discussions all happen in a shared
> space, which makes it easy to stay informed with everything that's going
> on (do we really need more mailing lists to follow? I don't think
Hi Hartmut,
> ...checking requirements: ERROR: trytond-party==6.0.2 (python-stdnum
> 1.14 (/gnu/
> store/04i1p7rw5583g0la8d66qwzwlfs9rvhg-python-stdnum-1.14/lib/python3.9/site-pac
> kages), Requirement.parse('python-stdnum>=1.15'), {'trytond-party'})
it means that the package trytond-party
Hello Ricardo,
> So… since numpy 1.20 is the exception here, could we perhaps …
> rename it? And then have python-numba import that renamed module
> “totally-not-numpy” instead of “numpy”? Could we thus avoid this
> conflict? If renaming is an option — how would it be done? Is it
> enough
Hi Théo,
> Ok I see, it makes more sense now. But then I wonder why I could package
> "python-ipydatawidgets" with "python-setuptools" and
> "python-jupyter-packaging" as native-inputs. I had no collision warning
> but didn’t change anything in "python-jupyter-packaging" or anything.
as far as I
Hi Théo,
> I don’t understand how this could happen though since the definition of
> python-setuptools seems just fine in python-xyz.scm ...
unfortunately our python package bundles setuptools 41.2.0, which will
collide with python-setuptools. I ran into the same issue with
Hi Maxime,
> Currently, non-Linux is not supported by the GHC package. However,
> people learn how to package things by example (and by reading
> documentation, etc.), so I'd prefer to avoid (accidentally) teaching
> people to make their package definitions Linux-specific.
do we have any
Hi Maxime,
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=89de1924cb535fc2c97d3654e21badaebd43518e
>
> > + ,@(if (string=? "i686-linux" (%current-system))
> […]
>
> Barring any reports of the contrary, I'd presume the same would
> apply for the Hurd. Also,
Hi Ludo’,
> Right. PyPI/setup.py/.whl doesn’t contain info as to how to run tests,
> right?
technically setup.py has a standard test target, but it’s been
deprecated for years and it must be enabled manually by the project. I’m
not aware of any standard pyproject.toml approach to this. It might
Hi Ludo’,
> My understanding is that most of them require manual intervention—i.e.,
> one has to tweak what ‘guix import’ produces, even if we ignore
> synopsis/description/license, to set the right inputs, etc. If we were
> to estimate the fraction of imported packages for which manual changes
Hi everyone,
it looks like eudev, which we heavily rely on, is dead upstream:
https://github.com/gentoo/eudev/issues/199
Looking at Gentoo’s ebuilds it should be possible to “extract”
and build udev from systemd’s sources.
Cheers,
Lars
Hi,
> From my point of view, yes you can push because it is a fix.
pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
hesitate to ping me if there’s any other issuse with the sanity check
phase.
Cheers,
Lars
lash.
See attached patch for a fix.
Can I simply push that to core-updates-frozen or is there anything else I
should do?
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz
Hi Chris,
> So, I think I've recently switched to thinking about the problem as one
> of testing changes, rather than just testing patches. Since both patch
> series, and branches are used to propose changes, I think this makes
> sense.
I agree with this analysis and this was always something
Hi Christopher,
> Anyway, I wouldn't like for this change to lower the standard though,
> it's currently the only package in Guix with an invalid description (as
> far as I'm aware), is there some reason why it doesn't have one?
it simply fell through the cracks[1]. Commit
packages so far.
Cheers,
Lars
>From a7c6750917f5dc2e1eaf34520f7e6b0e3d5e0d3c Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Tue, 6 Jul 2021 14:13:51 +0200
Subject: [PATCH 1/2] dirty: build: Build Python packages using pip.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Conten
Hi Hartmut,
> What should be the use of having a package without pip? Anything else
> than saving a few KB?
saving some space and unvendoring components that we also have separate
packages for. (As I understand it, ensurepip, which installs both pip and
setuptools, is merely a convenience tool
Hi Hartmut,
> sorry for being late for commenting on this (the time I can spend on
> guix is rather limited atm).
no problem, same thing on my side.
> *
>
> Not installing pip by default might break some user's environments.
> Anyhow, since using pip in guix is not such a good idea
Hi Tanguy,
(cross-posting this to the issue itself too)
> Sorry if I'm (very) late, but apprently this hasn't made it to master
> yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
> person to review or discuss your patch?
the patch set works, I can build many Python
Hi everyone,
just a quick reminder that an updated version (includes
python-toolchain) of this proposal is still looking for a code review or
further discussion. So if you feel confident about touching
python-build-system, please have a look at
https://issues.guix.gnu.org/46848#1
I’d be nice to
Hi Ricardo,
> Is there a way we can improve the quality of those Python packages that
> have tests disabled? I’d like to gain more confidence in these packages
> and be sure that at least all dependencies are among the inputs.
there is a new sanity check phase on core-updates, which should solve
Hi Pierre,
> Instead, I'd like the following behaviour:
> […]
hm, I feel that’s unnecessarly complex with lots of if’s and else’s. If
I could design the frontend from scratch, I’d have one command that does
profile/environment manipulation (because they’re essentially the same)
and one that can
Hi Pierre,
> My only complaint is that it's still a bit slow:
> Is there anything we can do to speed this up?
yeah, true. I’m think it’s still computing and building derivations, for
example using manifest->derivation for `prof-drv` and then again
built-derivations for `prof-drv`. Maybe if we
Hi Pierre,
> Do you have a link?
sorry, I meant, I wrote the patch that added the --profile switch, see
https://issues.guix.gnu.org/46291
> I'd love to see this merged! :)
The patch above is already merged.
Cheers,
Lars
signature.asc
Description: PGP signature
Hi everyone,
today I’m joining the Guix family as a new committer. Some of you might
know me already from guix-patc...@gnu.org or the last Guix Days in
Brussels, which I also attended.
I’m mainly working on Python and R packaging as part of my job at
leibniz-psychology.org. Apart from that I’ll
Hi,
> guix environment doesn't allow --ad-hoc to be used when --profile is
> set. I propose to have --ad-hoc add more packages to the container when
> using it with --profile.
I wrote the patch that adds this feature to `guix environment`. The idea
was to have a way to turn an existing profile
Hi,
very interesting read.
> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could
Hi Ryan,
> I think if we do that then Python will need a treatment similar to GCC,
> where we don't expose the package and instead offer a compound package
> (could be called "python-toolchain" or just "python") which includes pip
> and setuptools. The last decades of python packaging have
Hi Tanguy,
> Done! :-)
> I've eventually succeeded in ("properly") packaging a software managed
> with Poetry. And I've learned quite a lot on the way!
oh, I see. I’ve actually been trying to replace python-build-system with
a python-build based build. Attached is my current work in progress. I
Hi,
for reference, the patchset is now tracked by issue 45712
(http://issues.guix.gnu.org/45712)
Cheers,
Lars
Hi Vincent,
> I like the idea of better testing for our python packages, but would it be
> possible to avoid embedding the python code as scheme strings ?
> Like in a separate pure-python file.
I don’t know how unfortunately. Any ideas?
I moved it into a separate top-level variable now and
Hi Tanguy,
> So, I've tried packaging `python-keyring` with those two…
>
> `pep517` keeps on trying to download dependencies, which won't work.
>
> `build` crashes with "ZIP does not support timestamps before 1980",
> which, I guess is related to the fact that everything in the store is
>
Hi Hartmut,
> this is a good idea. (Since you where mentioning setuptools, I first was
> afraid your solution would be tightened to setuptools, but it is not.
> Well done!)
afaik pkg_resources is technically a part of setuptools, although it is
distributed with Python.
> This comment should go
* Python
packages broken by this new phase. I’m also aware this change needs to
go to core-updates.
Cheers,
Lars
>From 919fd78b1aff6c277baca396ef962a5dcd4e23ae Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Sun, 3 Jan 2021 10:30:29 +0100
Subject: [PATCH] [WIP] build-system/python: Valid
Hi,
> […] from my point of view, the good direction would be a “web-app frontend”,
> similarly to git-annex-assistant [1]. This design is more flexible because
> it could be used locally *and* could also be the front-end of some servers
> (e.g., build farms).
I have something like this on my
Hi,
> > Also, what about .pyc files? Does pypy create compatible .pyc files?
> Well, the .pyc generated by CPython should be compatible with the ones
> generated by Pypy, both VM targeting say Python 3.6.
> But there is no necessary compatibility between .pyc of Python 3.6 and
> Python 3.8, at
Hi,
> pypy3 works somewhat well for me already in this regard:
indeed, you’re right.
This will probably break for some packages, because python provides
Python 3.8 whereas pypy3 provides Python 3.6. (They’ve always lagged
behind and given that we’re going towards 3.10, well…) One example are
1 - 100 of 104 matches
Mail list logo
