[Distutils] Re: Linux binary wheels?

On Tue, Aug 20, 2019, at 5:05 AM Matthew Brett wrote: > ... Unless you meant wheels for non-Intel platforms, in which case, > please do say more about you need. Minor tangent: I've seen some people use https://www.piwheels.org/ for Raspberry Pi (ARM 6/7), but could the ARM binaries be

Re: [Distutils] Python Install

You need to run pip from a normal shell, e.g. bash/cmd.exe/PowerShell, not the Python REPL (read-eval print loop) "shell". On Sun, Feb 25, 2018 at 10:49 AM, wrote: > I am new to Python but would like to install to play with some Fast > Artificial Neural Network

Re: [Distutils] PyPi’s predictable download url

On Tue, Jul 25, 2017 at 4:25 PM, Noah Kantrowitz wrote: > > > On Tuesday, July 25, 2017, Alexander Belopolsky < > alexander.belopol...@gmail.com> wrote: > > $ curl -i http://pypi.org/pypi/virtualenv/json > > HTTP/1.1 403 SSL is required > > ... > > > > To explain this:

Re: [Distutils] PyPi’s predictable download url

On Tue, Jul 25, 2017 at 3:07 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > On Tue, Jul 25, 2017 at 3:33 PM, Nick Timkovich <prometheus...@gmail.com> > wrote: > > On Tue, Jul 25, 2017 at 1:45 PM, Aleks Bunin <b...@enlnt.com> wrote: > .. &g

Re: [Distutils] PyPi’s predictable download url

On Tue, Jul 25, 2017 at 1:45 PM, Aleks Bunin wrote: > I’m writing installation instructions for a package and have a question: > what is the correct predictable URL for the package? > I would guess you need to start from the API (e.g. https://wiki.python.org/moin/PyPIJSON) and

Re: [Distutils] Malicious packages on PyPI

ge names and/or make some lazy malicious users give up. ;) On Fri, Jun 2, 2017 at 8:05 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 2 June 2017 at 19:42, Richard Jones <rich...@python.org> wrote: > > On 2 June 2017 at 18:05, Nick Coghlan <ncogh...@gmail.com>

Re: [Distutils] Malicious packages on PyPI

I suggested on one of those issues to try to auto-blacklist common 404s as that should pose a negligible usability hit. I'd like to start by logging them to collect data, but I'm confused nowadays as to if that should go into pypa/warehouse or pypa/pypi-legacy. How long until warehouse is where

Re: [Distutils] Malicious packages on PyPI

This issue was also brought up in January at https://github.com/pypa/pypi-legacy/issues/585 then just as after the initial "typosquatting PyPI" report (June 2016) it's met with resounding silence. Attacking the messenger doesn't seem like a winning move from a security standpoint. Can we come up

Re: [Distutils] PyPI abuse

Other devils advocate: having *someone* park them, even if they're not the trademark holder, might be useful. If someone wants to go over what should be a relatively low bar to usurp the "holder", great. I'm thinking of the apple/android/angular/osx/ubuntu crop. On Tue, Apr 11, 2017 at 4:41 AM,

Re: [Distutils] Data on requirement files on GitHub

Looks like a fun chunk of data, what's the query you used? Can you add a README to the repo with some description if others want to iterate on it (maybe look into setup.py's?) Nick On Tue, Mar 7, 2017 at 5:06 AM, Jannis Gebauer wrote: > Hi, > > I ran a couple of queries against

Re: [Distutils] RFC: PEP 541 - Package Index Name Retention

If you have a non-release release with some description text and a home-page that points to where active development is going on (that could constitute "functionality" in a non-code way), I think that should preempt a reasonable person (which is hopefully a superset of maintainers) from deleting

Re: [Distutils] RFC: PEP 541 - Package Index Name Retention

This is a great PEP, glad to see an official policy being worked on! The "reachability" criteria I think should define how promptly the responses are expected and to what email(s) they will be sent (if there are multiple maintainers, owners, authors, etc.). For example, "the first contact will be

Re: [Distutils] Can't upload sdist: "File already exists"

No. My build command was: `python setup.py sdist bdist_wheel` which doesn't generate a zip. On Thu, Jan 5, 2017 at 2:13 PM, Ethan Furman <et...@stoneleaf.us> wrote: > On 01/05/2017 11:37 AM, Nick Timkovich wrote: > > I never determined what was causing my problem, I cou

Re: [Distutils] Can't upload sdist: "File already exists"

I never determined what was causing my problem, I couldn't reproduce it on testpypi so I gave up (it's a small package, and if someone wants the source, they can look at the GH link I have in the metadata). Specifically, why does it say that the file exists, but I *can not see it anywhere*,

Re: [Distutils] Can't upload sdist: "File already exists"

ease > version format is; on my phone so a pain to look up right now). > > On Wed, Dec 21, 2016, 12:30 Nick Timkovich, <prometheus...@gmail.com> > wrote: > >> I have a little package "huffman" where I build an sdist and wheel >> (python setup.py sdist bdi

[Distutils] Can't upload sdist: "File already exists"

I have a little package "huffman" where I build an sdist and wheel (python setup.py sdist bdist_wheel) and both seem to get built and can install fine. I can't seem to upload both to PyPI because the "File already exists": $ twine upload dist/* Uploading distributions to

Re: [Distutils] Interrogate distribution for an entry point command path

d.au> wrote: > Nick Timkovich <prometheus...@gmail.com> writes: > > > Usually that entry point is on the PATH […] > > It's not, because I'm deliberately specifying that it shouldn't be, at > install time. This is an executable that is private to the application >

Re: [Distutils] Interrogate distribution for an entry point command path

Usually that entry point is on the PATH, so it should be somewhere in os.environ['PATH'], so if you just `subprocess.run(['myentrything'])` that would fire it. If you want to call that entry point from your code, the clean way (same environment/version, and especially if you don't need to bother

Re: [Distutils] license for setuptools

Might be wandering away from simply tacking on a license, but some related legalese: Is there some canned contributor license agreement (CLA) that could also be applied to make clear that contributors must license their contributions to the project(s) in kind? Python has it's own (

Re: [Distutils] Outdated packages on pypi

A more conservative approach might be to flag high-risk, typo-prone package names as requiring moderator approval to register. Some combination of looking at common 404s (or whatever happens when a client asks for a non-existent package), some string metrics (Levenshtein, Jaro, whatever) to an

Re: [Distutils] Request for comment: Proposal to change behaviour of pip install

Jaded dev-ops person in me says that "pip install requests" in production is crazy anyways; thou shalt pin versions. If pip install with an implicit "--upgrade" could ever break something, you're just trading six for a half dozen because you're not guaranteed to be at a consistent state either

Re: [Distutils] Alternate long_description formats, server-side

Coghlan <ncogh...@gmail.com> wrote: > On 2 June 2016 at 15:19, Donald Stufft <don...@stufft.io> wrote: > > On Jun 2, 2016, at 6:08 PM, Nick Timkovich <prometheus...@gmail.com> > wrote: > > So yea, we need some sort of standard. It could be as simple as just

[Distutils] Alternate long_description formats, server-side

When I brought up enabling Markdown previously, I was a bit over-eager and started talking implementation before there was any sort of consensus about it in principle, so it was a bit of a straw-man. The previous discussion seemed to rest with the onus being on the user to do it themselves,

[Distutils] Basic Markdown Readme Support

GFM/SO stuff: fenced_code, smart_strong, nl2br Nick Timkovich Amaral Lab, Northwestern University [1]: https://github.com/pypa/readme_renderer/pull/3#issuecomment-72302732 [2]: https://github.com/pypa/readme_renderer/pull/3#issuecomment-66569248 ___