[Distutils] Re: PEP 440 Issue

lt;http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > <#m_3295279858084880915_m_7829119531011239564_DAB4

[Distutils] Re: Provide a way to bundle and extract license files

d hopefully will help take only 100 years instead of the original > thousand years needed to fix the problem (See > https://clearlydefined.io ) Oh, very cool! Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@py

[Distutils] Re: Provide a way to bundle and extract license files

PEP) will take years to cover a significant proportion of published packages (and there's a long tail of rarely updated projects that may never catch up). -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send

[Distutils] Re: "requirement" corner case

On Thu., 30 Jan. 2020, 10:02 am Gordon Messmer, wrote: > On 1/29/20 3:45 PM, Nick Coghlan wrote: > > > > Should I convert ">1.0.*" into ">=1.0" and mimic the current > behavior, > > or into something else, like "> 1.0", or

[Distutils] Re: "requirement" corner case

On Tue., 28 Jan. 2020, 3:52 pm Gordon Messmer, wrote: > I'm working on tools to convert python packaging data to rpm spec > files. Most of the conversions are relatively straightforward, but > there's an odd corner case with ">" and versions ending in ".*". That > combination is parsed as a

[Distutils] Re: python3 prefixed package RPMs

rom that. If you do decide to go down that path, then https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/ would be the best place to contact for more info/assistance. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing

[Distutils] Re: Review help: Automatic detection of macOS platform tag

On Wed., 16 Oct. 2019, 4:52 am Alex Grönholm, wrote: > There's a pull request against wheel that I feel out of my depth > reviewing: https://github.com/pypa/wheel/pull/314 > > I'm looking for anyone with experience on macOS binary compatibility to > help validate the solution. Help is really

[Distutils] Re: Linux binary wheels?

page that a custom error message could link to. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distut

[Distutils] Re: timeline for new pip resolver rollout - feedback?

idea (it's a distinct skillset, and large parts of it can take place alongside the refactoring and development). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-

[Distutils] Re: distutils.util.get_host_platform() and AIX

On Thu, 15 Aug 2019 at 03:03, Michael wrote: > > On 14/08/2019 15:09, Nick Coghlan wrote: > > I am guessing - that would be a PR for CPython - to get that into distutils. > > Not really, since the platform tag generation needs to work on older > Python versions. > > O

[Distutils] Re: setuptools (was distutils...) and AIX - getting to PEP427 or PEP491

> I repackage as installp (AIX installp manager) packages. Does "pip wheel" work? If not, you may be missing the "wheel" project from your environment (pip and setuptools will do their best to make "pip install" still work even if they don't have the required depe

[Distutils] Re: distutils.util.get_host_platform() and AIX

.org/specifications/platform-compatibility-tags/ You shouldn't have the same challenges that manylinux did when it comes to determining a suitable build environment, though - IBM are already doing that work for AIX, just as MS do it for Windows, and Apple do it for Mac OS X. What you may need to

[Distutils] Re: WIll custom setup.py with (set library-prefix have post install actions) continue to be supported ?

ld helper, etc could potentially consume that extra information to determine which commands to run after the base install to run the extra platform integration steps. I'm not aware of anyone specifically working on that problem yet, though, so it's wide open to anyone that thinks it sounds like a pot

[Distutils] Re: enscons 0.7.0 released with PEP517 support

to build itself and rsalette (another > enscons-using package) using pep517. Very cool :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org h

[Distutils] Re: PEP 376 & pkgutil - Quick question

d https://github.com/python/peps/issues/998 to note that we should clean up that old "Implementation Details" section in PEP 376 to better match what actually happened. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distuti

[Distutils] Re: Fwd: BitBounc BS Was: psycopg2/psycopg2-binary

dress, so we'll how persistent they are. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.p

[Distutils] PEP 440: restriction of numeric version components to ASCII digits made explicit

(and reflects what tools actually support), so I've merged Frazer's change at https://github.com/python/peps/commit/1dd991e9001ffea6b41e9a2cd3a6549dd984b89b to fix the omission and update the `is_canonical` regex to be consistent with the version parsing one. Cheers, Nick. -- Nick Coghlan

[Distutils] Re: PEP-582 concerns

ry based on the Python version in use, while the downside is that you potentially end up with multiple copies of the dependencies, even when they could have been shared without any problems. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailin

[Distutils] Re: Generalize sys.executable replacement from scripts to data_files (or more)

t; marker logic to look up its own RECORD file to find a rewritten script file and extract the shebang line from that file? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to dis

[Distutils] Re: Building local versions with pip wheel

the build backend. The pep517 helper library at the very least works that way: https://github.com/pypa/pep517/blob/2f97e1bd61e63a1c2d3979cafe7fd8c7689c9bde/pep517/wrappers.py#L139 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- dist

[Distutils] Re: Update PEP 508 to allow version specifiers

be automated by defining an additional `source` location in each project's Pipfile. Tools like devpi, pinrepo, Artifactory, etc can also be considered as potentially nicer ways of managing steps 2 & 3. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distu

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, 29 Jan 2019 at 23:29, Jan Musílek wrote: > > Nick Coghlan wrote: > > So URL specifiers replaced the part of dependency links that we > > actually wanted to keep: letting projects *temporarily* depend on VCS > > repos and other URLs while waiting for a release co

[Distutils] Re: Update PEP 508 to allow version specifiers

y* depend on VCS repos and other URLs while waiting for a release containing the feature that they needed, while focusing on abstract dependencies outside those cases (and deliberately eliminating the ability to add arbitrary new repositories to the dependency resolution process). Cheers, Nick. -- N

[Distutils] Re: PEP 517 - source dir and sys.path

clude the build directory on sys.path remains the right way to go. Thomas's https://github.com/takluyver/intreehooks then addresses opting in to that in the general case, while Paul Ganssle's proposed build_meta_legacy backend in https://github.com/pypa/setuptools/pull/1652 addresses it for the speci

[Distutils] Re: pyproject.toml (PEP518), build isolation (PEP517) and optional build dependencies

ojects, conda-specific projects, etc. Setting "--platform-dependent-build" as the default would then be a task for end user's pip configuration files (and potentially application dependency management tools like pipenv). It definitely wouldn't be appropriate for packages to set it implicitly.

[Distutils] Re: Building local versions with pip wheel

On Fri, 4 Jan 2019 at 16:50, Nick Coghlan wrote: > > On Thu, 3 Jan 2019 at 11:13, Bert JW Regeer wrote: > > Is there some way to influence the egg info for the build when using pip > > wheel? Some thing like: > > > > pip wheel > > git+https://github.

[Distutils] Re: Building local versions with pip wheel

Unpack the original wheel archive 3. Make any desired changes to wheel contents and/or metadata 4. Repack the modified wheel (potentially with an updated RECORD file and modified filename) auditwheel's own utilities for doing that kind of thing are here: https://github.com/pypa/auditwheel/blob/ma

[Distutils] Re: Idea: perennial manylinux tag

the wheel name, rather than needing a lookup table. Installers that wanted a more robust heuristic could still add extra checks based on the actual linking constraints defined by the reference build environment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --

[Distutils] Re: Idea: perennial manylinux tag

On Mon, 3 Dec 2018 at 23:11, Paul Moore wrote: > > On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote: > > P.S. Paul asked how we can have manylinux tags without updating PEP > > 425 to include them, and the answer is that the actual compatibility > > t

[Distutils] Re: Idea: perennial manylinux tag

can have manylinux tags without updating PEP 425 to include them, and the answer is that the actual compatibility tag spec is at https://packaging.python.org/specifications/platform-compatibility-tags/ and that references PEP 513 (manylinux1) and PEP 571 (manylinux2010) in addition to PEP 425. -- Nick Co

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

On Tue., 2 Oct. 2018, 4:05 pm Chris Jerdonek, wrote: > > In general, I think it's better to be more open about long-term strategies > within an organization and who is working on what and toward what goals, > etc. That way people can make better decisions about what to work on and > how to spend

[Distutils] Re: setuptools configuration in pyproject.toml

es: you need those in order to build the release artifacts, so it makes sense to put them in the input file. However, even there, PEP 517 offers a mechanism for the build system to request installation of additional dependencies dynamically) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

[Distutils] Re: setuptools configuration in pyproject.toml

tuptools_pyproject_cfg.read_config())" instead of hardcoding the args in setup.py And then at some point in the future (once the input format was stable), the boilerplate could migrate inside setuptools itself, and the build-requires and configuration table name would change accordingly. Cheer

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

t theses packages and their dependencies installed into the currently active environment". If it helps, think of pipenv relating to pip in much the same way as pip-tools (pip-compile/pip-sync) relates to pip, just with Pipfile and Pipfile.lock instead of requirements.in and requirements.txt. Cheers, N

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

of it wouldn't look the same as it does in pipenv (since it would be an opt-in thing to request to track your changes to the current environment, rather than the default behaviour, and because pip *wouldn't* gain the ability to generate `Pipfile.lock` directly, only the ability to derive one from

[Distutils] Re: Distlib vs Packaging (Was: disable building wheel for a package)

that's intended to be checked in to source control is where I draw the line between "component installer" and "application/environment dependency manager". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- dis

[Distutils] Re: New virtualenv maintainer

at! (and thank you for volunteering!) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/d

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

re to ever start running auditwheel on upload, and subsequently hide manylinux wheels that failed the check (such that installers were able to properly meet the binary compatibility assurances nominally offered by the specifications). Cheers, Nick. [1] https://github.com/pypa/manylinux/issue

[Distutils] Re: pip installing scripts into another virtualenv

can also be uninstalled afterwards if the aim is to minimise the size of the shipped virtualenv, and any future updates will be handled by replacing the entire virtualenv rather than modifying it in place. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mai

[Distutils] Re: PEP 518 and the pyproject.toml format

, and whether there's something that could be offered at the pyproject.toml level that would better enable portability of projects across different deployment tools. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@pyt

[Distutils] Re: Adopting virtualenv package maintenance

the code from it, and have it just handle the parts that venv itself doesn't cover in any given version of Python :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-si

[Distutils] Re: Environment markers for GPU/CUDA availibility

r the available glibc version if there's no "_manylinux" module to give an explicit answer). For the GPU case, the naive check (at least initially) could just be "False", and folks would have to set the explicit marker in order to opt-in to the GPU accelerated variant. Cheers,

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, 4 Sep 2018 at 20:30, Nathaniel Smith wrote: > > On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > > wrote: > >> > >> > >> What’s the problem with including GPU and non-GPU variants of co

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, wrote: > > What’s the problem with including GPU and non-GPU variants of code in a > binary wheel other than the size of the wheel? I tend to prefer binaries > that work “everywhere", even if that requires some more work in building > binaries (such

[Distutils] Re: Environment markers for GPU/CUDA availibility

you're actually going to import. Cheers, Nick. P.S. As an alternative to a magic module, the install marker overrides could be placed in pyvenv.cfg. Even if we did that, we'd probably still want the magic module option though, as pyvenv.cfg doesn't exist for user-level and interpreter-installation-l

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

e "cp36-none-any" for a bytecode-only wheel archive that *only* ran on CPython 3.6, and wouldn't be portable to other versions or implementations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To

[Distutils] Re: Clarification on string arguments in PEP 517 hooks

On Mon., 20 Aug. 2018, 11:54 pm Paul Moore, wrote: > > My assumption is that the intent is that *all* strings, whether > arguments or return values, must be Unicode. > Handling bytes paths correctly cross-platform is a pain, so I think requiring frontends to always pass in Unicode makes sense.

[Distutils] Re: Is ensurepip still a thing?

On Wed., 8 Aug. 2018, 7:02 am Chris Barker via Distutils-SIG, < distutils-sig@python.org> wrote: > On Tue, Aug 7, 2018 at 9:16 AM, Donald Stufft wrote: > > >> > Or really, the question at hand: should a user starting from scratch >> > with a python.org install of 3.7 run ensurepip? >> > >> > Or

[Distutils] Re: packaging guide and private packages index

they're still learning is "your time as a developer is expensive, so you typically don't want to build what you can already buy"). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscrib

[Distutils] Re: Timestamp of installed files

t; just works most of the time. None of this affects reproducible builds, as the whole point of SOURCE_DATE_EPOCH is to allow everything that affects the final output artifacts to *ignore* the modification times on any checked out, generated or unpacked files. Cheers, Nick. -- Nick Coghlan | ncogh..

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

ep the base application up to date, but use application provided tooling to keep the plugins up to date. If you did that, then the plugins wouldn't get native system packages at all - they'd all remain solely as Python packages, and then the system level certbot package would install a priv

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

On 25 July 2018 at 12:39, Nathaniel Smith wrote: >> On Jul 24, 2018, at 4:36 AM, Nick Coghlan wrote: >> >> However, there *are* folks that have been working on allowing >> applications to be defined primarily as Python projects, and then have >> the creatio

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

service.org/ (Fedora's COPR is good for targeting RPM based distros, and Ubuntu offer their PPA system, but OBS allows creation of multiple respository formats). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.o

[Distutils]Re: Approaching wheel 1.0

commented where I could, but that was basically just the ones where you seemed to be pondering possible command line UX options - for the ones related to the actual extension module build process, I believe you already know significantly more than I do :( Cheers, Nick. -- Nick Coghlan |

[Distutils]Re: ssl error in installing packages

e else to help diagnose your situation, it will require more information about your system configuration. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

if this is > a misuse of the list. If so, please ignore. I was torn wether or not this is > appropriate. Making folks aware of new contenders in the Python-app-distribution space is definitely a reasonable use of the distutils-sig list :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

[Distutils]Provisional PEPs can now actually be marked as Provisional

although I expect PEP 518 isn't too far off being marked as Final - the question of the precise meaning of a missing build-system table when pyproject.toml is present seems to be the only underspecified point that anyone has found during the Provisional period). Cheers, Nick. -- Nick Coghlan

[Distutils]Handing over default BDFL-Delegate responsibilities for packaging interoperability PEPs to Paul Moore

aging User Guide and pipenv maintenance, and will continue as a member of the PSF's Packaging Working Group. However, the final sign-off for packaging interoperability PEPs will now rest with Paul or someone else that he appoints, rather than with me :) -- Nick Coghlan | ncogh...@gmail.com |

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

support pyproject.toml files that have already opted in to build isolation by writing: [build-system] requires = ["setuptools", "wheel"] Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@pytho

[Distutils]Re: Possible change to PEP 517: look up the backend as $BACKEND.__build_backend__?

virtue of keeping PEP 517 as simple as we can reasonably make it). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mai

[Distutils]Re: Possible change to PEP 517: look up the backend as $BACKEND.__build_backend__?

e seems fine to me, but I think it would be a problem if direct references like `build-backend = "flit.buildapi"` didn't work. That is, the override check would be: backend = getattr(backend_ref, "__build_backend__", backend_ref) Cheers, Nick. -- Nick Coghlan

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

urrently upgrade to newer versions of the affected projects. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/

[Distutils] Re: Discussion/direction for platform/abi options being added to pip's "install" and "wheel" subcommands

y expect to see is that specifying any of those options also imply "--only-binary :all:" (rather than requiring it to be passed in separately). That could wait to a follow-up PR though (since the current PR just throws an error in that case). Cheers, Nick. -- Nick Coghlan | ncogh...@gm

[Distutils] Re: sudo pip install: install pip files into /usr/local on Linux?

On 1 June 2018 at 02:11, Wes Turner wrote: > On Thursday, May 31, 2018, Matthias Klose wrote: > >> On 26.05.2018 14:59, Nick Coghlan wrote: >> >> > Yep, after all the other entries. I actually think Debian/Ubuntu may >> have >> > changed their defau

[Distutils] Re: sudo pip install: install pip files into /usr/local on Linux?

On Sat., 26 May 2018, 4:25 am Donald Stufft, wrote: > > > On May 25, 2018, at 12:44 PM, Thomas Kluyver wrote: > > It's more annoying for scripts - on common Linux distributions, the user > scripts location ~/.local/bin is not on PATH by default. > > > >

[Distutils] Re: proposing Python package index upload API spec (potential PEP)

p-0517/#source-trees The equivalent here would be to call the existing upload interface the "v1 upload API", and cite the relevant Warehouse endpoint URL as the reference implementation for it. While I initially wasn't a fan of that idea, the effectiveness of the approach in PEP 517 now make

Re: [Distutils] This list will soon be migrating to Mailman 3

On 24 April 2018 at 00:05, Nick Coghlan <ncogh...@gmail.com> wrote: > I'm currently planning to send the migration request to > postmas...@python.org later this week (probably Thursday evening), but > don't have an ETA for how long the actual migration may take after >

[Distutils] This list will soon be migrating to Mailman 3

://mail.python.org/pipermail/core-workflow/. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Improving Communication

place on distutils-sig. The onus would then be on those of us that wanted to participate in the API 2.0 design discussions to adapt to the Warehouse community's chosen toolset, rather than requiring that those discussions be restricted to the existing toolset. Cheers, Nick. -- Nick Coghlan

Re: [Distutils] Improving Communication

y handling the list admin responsibilities for distutils-sig. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Feed of latest releases on pypi.org

of the status of any search syntax changes, but the Warehouse RSS feeds are covered at https://warehouse.readthedocs.io/api-reference/feeds/ (those feeds did exist on Legacy PyPI, but the Warehouse implementation tidies up some inconsistencies in the data they provide) Cheers, Nick. -- Nic

Re: [Distutils] Package metadata: which fields are optional

says PyPI doesn't check that it's there, but if all (or > almost all) distributions have it anyway, maybe we should enforce that it's > always there. It's easy enough for consuming tools to default Summary to being the same as Name, so I'm OK with making it officially optional. C

Re: [Distutils] Package metadata: which fields are optional

e, it will become https://packaging.python.org/specifications/core-metadata/#keywords. Adding a ".. _keywords-optional:" label before the heading will preserve the old links. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

tting PRs to help guide the evolution of the stable APIs in packaging in a use-case driven manner. FWIW, `pipenv`'s currently still on "Step 1" at the moment (and has a lot of internal refactoring of its own ahead of it before it will really move on to

Re: [Distutils] Pip 10.0 has been released

bring this new release together and get it into the hands of end users :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 571: Any further manylinux2010 concerns or questions?

On 12 April 2018 at 21:54, Nick Coghlan <ncogh...@gmail.com> wrote: > On 30 March 2018 at 20:46, Nick Coghlan <ncogh...@gmail.com> wrote: >> PEP link: https://www.python.org/dev/peps/pep-0571/ >> >> Thomas Kluyver has amended Mark Williams's PEP 571 to address t

Re: [Distutils] Pip upgrade

ou're using virtual environments, then I would have expected the suggested command to work, but you'll need to run it in each affected virtual environment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG mai

Re: [Distutils] providing a way for pip to communicate extra info to users

ith the metadata generation process on the server. To resolve the problem, please force upgrade pip". That's a solvable problem (e.g. only check for the MOTD *after* successfully retrieving a valid metadata file), but it's still something to take into account. Cheers, Nick. -- Nick Coghlan

Re: [Distutils] PEP 571: Any further manylinux2010 concerns or questions?

On 30 March 2018 at 20:46, Nick Coghlan <ncogh...@gmail.com> wrote: > PEP link: https://www.python.org/dev/peps/pep-0571/ > > Thomas Kluyver has amended Mark Williams's PEP 571 to address the > concerns & questions raised in the previous thread: > > * manylinu

Re: [Distutils] Distributing packages to offline machines

On 7 April 2018 at 12:21, Wes Turner <wes.tur...@gmail.com> wrote: > > > On Friday, April 6, 2018, Ben Finney <ben+pyt...@benfinney.id.au> wrote: >> >> Nick Coghlan <ncogh...@gmail.com> writes: >> >> > Keep a requirements.txt file or `P

Re: [Distutils] Distributing packages to offline machines

ary dependencies", it may also be worth your while to explore https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/ (regarding the use of conda as a Python platform manager) and https://conda.io/docs/user-guide/tasks/create-custom-channels.html (regarding the creation of tar-fr

Re: [Distutils] [Python-ideas] Pypi private repo's

onvincing other community contributors that it's a good way to go :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was: PEP 571: Any further manylinux2010 concerns or questions?

On 3 April 2018 at 02:45, Trishank Kuppusamy <trishank.kuppus...@datadoghq.com> wrote: > On Sat, Mar 31, 2018 at 11:06 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> The main reason PyPI doesn't currently support distro specific wheels is >> because there isn't a

Re: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was: PEP 571: Any further manylinux2010 concerns or questions?

there were to be a significant growth in non-manylinux Linux wheels on PyPI, I'd expect them to be for the official Docker Inc base Python images, which are Alpine based, and hence can't use the glibc-based manylinux binaries. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] PEP 571: Any further manylinux2010 concerns or questions?

naconda platform compatibility) As I expect quite a few folks will be busy for the Easter weekend, I'm planning to accept the PEP a week from next Monday (i.e on April 9th) if no new concerns or objections are raised between now and then :) Cheers, Nick. -- Nick Coghlan | ncogh...@gm

Re: [Distutils] Removing wheel signing features from the wheel library

ould be deprecated or removed from the PEP entirely. > Cool, that's what I thought you meant, but I figured I should double check since our discussion was a while ago now :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] Removing wheel signing features from the wheel library

ing the format of RECORD would be a problem though, since it's a documented requirement that installers are expected to check those at installation time. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-

Re: [Distutils] Renaming this list to python-packaging

or list renames, but https://gitlab.com/mailman/mailman/issues/156 suggests that while the devs are open to the idea, it isn't supported yet. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist -

Re: [Distutils] Cannot install pyopencl

roblems installing particular projects, I'd also suggest investigating the assistance options for *that project*. In many cases, installation challenges are project specific, and it sounds like that may be the case here. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | B

Re: [Distutils] PyPI support for linux_ppc64le

ges himself. I don't actually know that for sure though - I'm just generalising from an approach that often works on me :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 566 - Package metadata version 2.1

o check what still needs to be added to bring it up to date with the accepted version of the PEP: https://github.com/pypa/python-packaging-user-guide/pull/412#issuecomment-368196414 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisban

[Distutils] PEPs 426 & 459 (metadata 2.0) have been Withdrawn

now back to referring solely to the never-adopted metadata 2.0. So while we may still revisit some of the specific ideas in 426 and 459 in future PEPs, any such proposals will share PEP 566's focus on ease of implementation and adoption. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

Re: [Distutils] Invalid Packages

On 18 February 2018 at 18:06, Nick Coghlan <ncogh...@gmail.com> wrote: > On 18 February 2018 at 03:48, Lele Gaifax <l...@metapensiero.it> wrote: >> Nathaniel Smith <n...@pobox.com> writes: >> >>> What do you mean by a "spam package"? I guess it

Re: [Distutils] Invalid Packages

packages (e.g. https://github.com/pypa/warehouse/issues/2268), that's a design & implementation question for PyPI as a service, rather than something that needs to be captured in a PSF policy document (and PEP 541 is the latter, hence the slightly modified approval process that involves the PSF more ex

Re: [Distutils] pypi.python Error 403 Forbidden

switched to HTTPS only). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] draft PEP: manylinux2

ay, > manylinux1, manylinux2, manylinux3, etc. Yep, exactly this (the idea originally came from the fact we're going to need a manylinux variant with a baseline year around 2014 or 2015, or potentially even later, if we want to support aarch64 and/or ppc64le). Cheers, Nick. -- Nick Coghlan

Re: [Distutils] draft PEP: manylinux2

nt of view, we can see that if we assume CalVer as the recommended path forward, then we wouldn't have a compelling argument for switching away from it to any of the other plausible schemes. Cheers, Nick. [1] Ah, that would bring back memories of BASI

Re: [Distutils] Installed Extras Metadata

f that split approach is that the "Database of installed extras" aspect would only requires enhancements to pip and other installers, and to tools that read the installation metadata, while the full proposal would also require changes to PyPI and to publishing too

Re: [Distutils] draft PEP: manylinux2

On 10 February 2018 at 16:03, Mark Williams <m...@twistedmatrix.com> wrote: > On Tue, Feb 06, 2018 at 05:55:36PM +1000, Nick Coghlan wrote: >> By contrast, year-based CalVer maintains distro-neutrality, while also >> giving a good sense of the maximum age of compatible targ

Re: [Distutils] draft PEP: manylinux2

l back to "have_compatible_glibc(2, 12)" if there's no `_manylinux` module, or if that module doesn't include a "_manylinux.manylinux2010_compatible" attribute. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

  1   2   3   4   5   6   7   8   9   10   >