Re: [Distutils] Basic Markdown Readme Support

[Alexander Walters]

The justification was "Because Github et. al. support markdown, pypi 
should too", presumably for the purpose of allowing one to write their 
README once, and have it work in both places.  This is already possible, 
and only adds unneeded complexity to an already complex system.  If you 
want to make your README a write-once document, use the format already 
supported on both platforms.


On 5/3/2016 00:27, Robert Collins wrote:



On 3 May 2016 4:19 PM, "Alexander Walters" <tritium-l...@sdamon.com 
<mailto:tritium-l...@sdamon.com>> wrote:

>
> I am -1 on this on the basis that the services mentioned also 
happily support restructured text READMEs


I don't understand why that makes you say no to the ability to support 
markdown.


Rob



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Alexander Walters]

I am -1 on this on the basis that the services mentioned also happily 
support restructured text READMEs


On 5/2/2016 12:40, Nick Timkovich wrote:
Markdown READMEs are becoming increasingly ubiquitous for many 
projects. GitHub, GitLab, Bitbucket, among others, happily detect .md 
readme files and render them in their web interfaces. rST is nice, but 
is generally overkill for single-page documents (as opposed to more 
intricate documentation). To get something done sooner, rather than 
later, I'd prefer to come up with a two-phase solution, one narrow and 
"opt-in" (status-quo for all existing packages unless the maintainer 
does something) for quick implementation with hopefully minimal 
pushback. The other, later, not-proposed-here, could be more 
feature-rich/heuristic.


So, to get Markdown supported in some form, here's some talking points 
to debate:


* Add a "long_description_filename" to setup (suggested by 
@msabramo/GH [1]), which does the usual boilerplate "[codecs.]open(x, 
'r', encoding=y).read()". To determine the format look at an 
additional "long_description_content_type" field (if provided), 
otherwise look at the file extension and assume/require UTF-8.


* As an alternative, if there is no long_description, and the 
fall-back to README.rst fails, look for README.md and grab that. Such 
a strategy wouldn't be fully opt-in, however.


* Markdown (just like reStructuredText) allows arbitrary HTML to be 
added. The renderer must then be upstream of the (existing) clean 
(with bleach) step.


* [Optional]: Use common extensions provided by the PyPI/Markdown 
library to 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


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Two ways to download python packages - I prefer one

[Alexander Walters]

Hypothetically, the alternative is to break non-application entrypoints 
(the ones NOT used for console scripts or gui applications) into some 
other infrastructure.  The people that use entrypoints for their plugin 
systems might be given a build system agnostic option if that were the 
case.  Console scripts et. al. are still build/install system dependent.


On 5/2/2016 03:16, Alex Grönholm wrote:
You make it sound like there's a plausible alternative to setuptools 
entry points -- is there?


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Parked Names in PyPI under user rodmena

[Alexander Walters]

On 4/21/2016 15:02, Chris Barker wrote:
Good evidence that the "first come first served, and then you get to 
keep it forever" is not ideal.


Criminal violations of trademark are evidence that its not ideal, and 
therefor we should make pypi untrustworthy for all other cases? This 
case is /criminal/ violation of trademarks.  This is different than 'I 
have a package that hasn't been updated for a year and you want my name 
on pypi'.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Alexander Walters]

I described at a high level what mypy-lang does to my wife, and the 
brief history of this issue.  Her blerted out solution was to "just 
change mypy-lang to annopy"  (for annotated python).  I am required by 
marital obligation to bring that forward.


On 4/18/2016 18:21, Glyph wrote:


On Apr 18, 2016, at 3:17 PM, Alex Grönholm > wrote:


This name is unfortunately a bit awkward in the author's native 
language -- it is the colloquial word for "babe" or "broad" :)


OK, I didn't see that one coming :-).

"stapy", then?  "static type annotation python"?

-glyph


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Name arbitration on PyPI

[Alexander Walters]

Here here.

As to the concept of a name being community owned vs. registrant owned - 
I am very opposed to changing the rules mid-stream.  If community 
ownership is to be a thing (and I do not want it to be a thing at all, 
but if it is), it should be *from this point forward* the names are 
community owned.


On 4/18/2016 18:16, Glyph wrote:


On Apr 18, 2016, at 3:11 PM, Donald Stufft > wrote:


If we mandated semver (or something like it) we could make it so that 
transferring a name *forced* a major version bump and the new author 
would be unable to release anything using a smaller major version 
number, people could then pin to 

[Distutils] Name arbitration on PyPI (was: The mypy package)

[Alexander Walters]

The idea of expiring out names has been brought up recently to resolve 
an issue of two packages, one popular and large; another someone's 
weekend project.  The general idea being that a project maintainer 
should be forced to renew their contact information, or face the 
possibility of the PyPI name they registered being de-registered and 
made available for another package to use.


Preamble done, let me enumerate why this is just a disaster:

1.  PyYAML is a package that would be de-registered in such a scheme.  
It is a highly used, extremely popular, package that unserializes text 
into arbitrary python objects.  It is a trusted package... and one that 
hasn't been active in ages.  This is prime malware bait.


2. the package tooling already assumes that names will always point to 
one, and only one package.  ever.  until the heat death of the universe 
or the death of the language whichever is first.  If I am the one person 
in the world who actually depends on the 'mypy' (not mypy-lang) package, 
you have broken that trust.


3. Who in the PSF really wants that bureaucratic nightmare of 
arbitrating cases when this inevitably messes up, be this system manual 
or automatic?


To the specifics of the mypy-lang package that brought this up... It's 
like naming your company "Yahoo", and getting upset that yahoo.com is 
getting a bump in traffic because of your popularity. It is unfortunate 
that the mypy-lang developers failed to check pypi for name availability 
before they named their package, but it is by no means a reason to 
invite malicious code into the index, break the trust of the tooling, or 
create a bureaucracy to manage when the first two happen.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Alexander Walters]

Greatly expanding the pool of names solves the problem.

On 4/18/2016 12:34, Chris Barker wrote:
On Mon, Apr 18, 2016 at 8:48 AM, David Wilson 
> wrote:


Namespaces seem like a great idea, then these problems disappear
entirely, 



huh? as far as I can tell, namespaces greatly expand the pool of 
available names, but other than that, we've got the same problem.


-CHB




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Alexander Walters]

On 4/18/2016 11:18, Chris Barker - NOAA Federal wrote:

Domain names are a different system -- you need to maintain your registration.
Except, that wasn't my point.  My point was I ignore people asking to 
buy my domain from me because the registered name is part of my identity.

PyPi names, on the other hand, are all too easy to setup, and then
completely ignore, maybe even forget you used it.

We really should have SOME way to determine if a PyPi name has been
abandoned. Or even be proactive--PyPi names must be maintained in SOME
way, perhaps:

Why?

Push a change or update at least once a year (or some other interval).

What if your code doesn't need an update?


Or

Respond to some sort of "do you still want this" email. At least once a year.

And how many times have you missed an automated email?

If neither of these occurs, then we could have a deprecation period.

Details aside, as PyPi continues to grow, we really need a way to
clear out the abandoned stuff -- the barrier to entry for creating a
new name on PyPi is just too low.
We absolutely do not.  Names are first come, first serve, in 
perpetuity.  Changing this changes the security model of pypi.  If all 
an attacker has to do is wait out an old, but still highly downloaded 
package... why wouldn't they do it?


This is all too late for MyPy, but it has certainly come up before,
and will again, more and more.

-CHB


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Alexander Walters]

On 4/16/2016 14:52, Paul Moore wrote:

We
>cant unilaterally hand over names on pypi to unrelated.. or even related..
>projects because they have a name someone else wants.

What I*meant*  to say here was that when a request for a name transfer
gets no reply, it's helpful to know if the email address is no longer
responding at all. Nothing more than that. That might help anyone
making a decision to decide what to do.

But no, I agree absolutely we can't just hand over names.

Paul
If what you intend is to just flag the index entries where the owner has 
a bouncing email as "Heads up, the owner's email doesn't work anymore", 
then I don't have any problems with that.


Though I do wonder how effective that would be in this case.  For all we 
know, in the case of mypy, the maintainer is simply ignoring someone 
else who is trying to take the name they registered.  (I get emails all 
the time for people trying to get me to sign over my domain names; even 
though I am not doing much with them, they are my names and my identity, 
so that is one possible reason.)
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Namespaces (was: The mypy package)

[Alexander Walters]

On 4/16/2016 12:53, Donald Stufft wrote:

On Apr 16, 2016, at 12:42 PM, Alexander Walters <tritium-l...@sdamon.com> wrote:

Another solution like adding namespaces to pypi sounds better to me... but then 
I think about the nightmare of implementing that in a backwards compatible way.

We already have namespacing sort of, people can make something like 
dstufft.mypy and that works fine. The main thing that doesn’t exist is there’s 
no way to claim an entire namespace to prevent someone else from taking 
something in your namespace.

However, I don’t think most people really want that, people like having shorter 
names that aren’t tied to a specific namespace generally.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

My thought when I made that suggestion (which I already dismissed as a 
nightmare for you brave souls who provide the index free of charge... 
thank you) was less in the realm of 'tritium.mypackage', where a user 
would claim their package namespace for all their code, but more along 
the lines of 'django/my.super.cool.app' or 'flask/my_extension' or 
'qa/mypy' and 'qa/flake8' - curated (or open...) namespaces of related 
packages.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Alexander Walters]

To what end?  As much as old packages cluttering the namespace of pypi 
is annoying, the only thing that will accomplish is orphaning projects.  
We cant unilaterally hand over names on pypi to unrelated.. or even 
related.. projects because they have a name someone else wants.


Another solution like adding namespaces to pypi sounds better to me... 
but then I think about the nightmare of implementing that in a backwards 
compatible way.


On 4/16/2016 04:36, Paul Moore wrote:

I wonder, however, whether it would be reasonable to add an explicit
policy to PyPI (probably at the point of the switch to Warehouse)
requiring project owners to provide an active email address (where
"active" means, say, responding to an annual automated ping email to
confirm the project is still alive).


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Alexander Walters]

Please keep in mind, my suggestion can be done *today* with zero changes 
to tooling.


On 4/5/2016 18:50, Alex Grönholm wrote:
Implementing this on Warehouse and pip would have the added benefit of 
warning users who have a specific version pinned. As for pip letting 
stderr messages through, that'd be irrelevant if pip had direct 
support for this. 


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Alexander Walters]

I am not 100% sure if pip will let stderr messages though, but i THINK 
it does.  Warnings on import will work regardless.


Honestly, I don't care if its marginally easier (and it would only be 
marginally easier) to mark a package deprecated by flipping a bit on the 
site - it's the last thing they will ever do with the package.


On 4/5/2016 18:40, Alex Grönholm wrote:
Wouldn't my suggestion or Glyph's be easier for the maintainers? That 
way they wouldn't even have to make a new release, just modify a 
setting on the package settings page on PyPI.

Also, are you going you see the warning if it's emitted on installation?

06.04.2016, 01:37, Alexander Walters kirjoitti:



On 4/5/2016 18:34, Glyph wrote:
Perhaps, before anyone tries to make pip doing something mechanical 
about deprecations, we should just have the website itself do this 
sort of redirect?  Removing the download would be drastic; giving 
people an interstitial that says "This package is no longer 
maintained, please use $X instead" would be very informative.


-glyph


I don't remember the last time I used the pypi website.  I use pypi 
every day.  I don't know if I am weird, but redirecting web views 
would do nothing for me.  Redirecting packages is pure evil.


I really think the best course of action is for the maintainer to 
release a final version of the package that warns on install and import.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Alexander Walters]

On 4/5/2016 18:34, Glyph wrote:

Perhaps, before anyone tries to make pip doing something mechanical about deprecations, 
we should just have the website itself do this sort of redirect?  Removing the download 
would be drastic; giving people an interstitial that says "This package is no longer 
maintained, please use $X instead" would be very informative.

-glyph


I don't remember the last time I used the pypi website.  I use pypi 
every day.  I don't know if I am weird, but redirecting web views would 
do nothing for me.  Redirecting packages is pure evil.


I really think the best course of action is for the maintainer to 
release a final version of the package that warns on install and import.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Alexander Walters]

The ideal solution is for the maintainer to release one last version of 
the package with copious use of the warnings module.


We really don't want to redirect people blindly - They may be depending 
on undocumented-but-still-api portions of the original's code that a 
replacement package might not implement - or more likely - the 
replacement would only have a similar, but not identical, api.


We really don't want to just remove the package - then dependencies 
break for people who can't upgrade their own codebase for whatever 
reason, or who just need to deploy fresh again.


We might want to implement a package metadata property - Pip can give a 
big flashing warning on install that the package is deprecated by the 
maintainer.  This should be the ONLY use of this property; let's not 
start making rules based on deprecation metadata, that's as bad as just 
removing the package.


This leaves, for me, one real option maintainers can do right now, and 
that's just warn the dickens out of the developer.




On 4/5/2016 14:46, Thomas Güttler wrote:

I wasted some time because I used a deprecated python package.

I asked the maintainer to remove it, and he looked at the usage statistics: I 
still gets
downloaded.

What is the official way to deprecate a python package?

Related discussion:

https://github.com/riklaunim/django-ckeditor/issues/60#issuecomment-205021579

Regards,
   Thomas Güttler



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-ideas] Version control system link in package meta data

[Alexander Walters]

I think that reiterates my point - the information infrastructure does 
not exist to make a tool that reliably works in the general case... 
today.  If Tymoteusz Jankowski develops a tool for their workflow, and 
it works, and they release it, maybe the status quo will change.


I think I am speaking to the reality of the situation in that there is a 
lot of momentum (dead weight not moving has momentum, too) in not being 
universally consistent with VCS urls on pypi.  I suspect that there will 
have to be a buildup of momentum opposing that before pypa (or some 
other interested body) moves to make the tool suggested really happen.


...

Which I guess means Tymoteusz Jankowski should probably get an alpha of 
such a tool out, and that might provoke the movement needed for the tool 
to succeed.


On 3/12/2016 09:46, Nick Coghlan wrote:

On 12 March 2016 at 20:44, Alexander Walters <tritium-l...@sdamon.com> wrote:

I agree, it would be nice if everyone used git (or any of a small set of
VCS), and all the packages on pypi listed their repositories in the
metadata.  If that were the case, this tool might already exist.  In the
current state of things, though, i don't think it makes much sense to
produce a general purpose tool for this.

We don't place any particular requirements on the development
practices of projects publishing their releases through PyPI, so
there's no requirement for a public VCS URL to even exist for a
project, let alone for it to be mentioned in the project metadata.

That said, since project URLs do make it possible for projects to
share that metadata if they want to, this is a situation where a
"checkout-pypi-project" that gained popularity might provide more
incentive for maintainers to provide that metadata and keep it up to
date. As a fallback for projects without that metadata, searching
popular hosting sites like GitHub, BitBucket, GitLab and even
SourceForge, would provide some initial links to investigate.

Cheers,
Nick.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-ideas] Version control system link in package meta data

[Alexander Walters]

(cross-replying to distutils-sig@python.org)

For a tool like this to work reliably, the semantics of the project urls 
would have to change (as of right now, there is no set requirement that 
a VCS link in project URL's point to clone>), nor is there a requirement that the field even be present.  For 
this to be useful for your tool, projects would have to be required, or 
at least heavily encouraged, to put VCS links in their pypi listings.  
Moreover, such a requirement would additionally need to limit what type 
of VCS links you post as to make the tool reasonable to maintain.  (Not 
everyone uses git, let alone github.  Do you want to write a tool that 
supports Team Foundation Server?)


Another option would be to pull in source packages with your tool, but 
that too would require that people actually post source packages for 
their projects on PyPI.  There is no such requirement as it stands, and 
the number of pure-python projects posting sdists may actually decrease 
with the uptake of universal wheels.


Automating this process is not impossible.  As you said, you could write 
your own tool to do it, but as it stands, even with that tool, you would 
have to do quite a bit of manual legwork still.


I agree, it would be nice if everyone used git (or any of a small set of 
VCS), and all the packages on pypi listed their repositories in the 
metadata.  If that were the case, this tool might already exist.  In the 
current state of things, though, i don't think it makes much sense to 
produce a general purpose tool for this.


On 3/12/2016 05:12, Tymoteusz Jankowski wrote:

Hi,
tldr: install project and its requirements as cloned repositories (if 
possible)


Let's say I'm developing requests 
 library which relies on 
these 
 packages.

My workflow is this:

$ git clone https://github.com/kennethreitz/requests.git
$ cd requests
$ virtualenv requests
$ . requests/bin/activate.fish
$ pip install -r requirements.txt

Now I can change Requests library easily and commit changes, but when 
i have to change a library from Requests' requirements I have to clone 
and reinstall library (It's boring + I'm lazy).

I need tool that works like this:

$ magic-command install requests
1 the tool checks in Requests package meta where sources are stored
2 clone the source
3 do the same for each package from requirements (or fallback to 
current method)


I could write the tool and be the only one in the world using it ;) 
but there should be an option for storing repository link.

Could you advice anything?
I found this:
https://www.python.org/dev/peps/pep-0345/#project-url-multiple-use
but
1 I'm not sure it's right option
2 I can't see handler for this option in distutils 





___
Python-ideas mailing list
python-id...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

[Alexander Walters]

On 2/1/2016 18:37, Matthias Klose wrote:

On 30.01.2016 00:29, Nathaniel Smith wrote:

Hi all,

I think this is ready for pronouncement now -- thanks to everyone for
all their feedback over the last few weeks!


I don't think so.  I am biased because I'm the maintainer for Python 
in Debian/Ubuntu.  So I would like to have some feedback from 
maintainers of Python in other Linux distributions (Nick, no, you're 
not one of these).


The proposal just takes some environment and declares that as a 
standard.  So everybody wanting to supply these wheels basically has 
to use this environment. Without giving any details, without giving 
any advise how to produce such wheels in other environments. Without 
giving any hints how such wheels may be broken with newer 
environments.  Without mentioning this is am64/i386 only.
There might be more. Pretty please be specific about your 
environment.  Have a look how the LSB specifies requirements on the 
runtime environment ... and then ask yourself why the lsb doesn't have 
any real value.


Matthias

I... Thought the environment this pep describes is the docker image, and 
only the docker image, and anything not made on that docker image is in 
violation of the pep.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] draft PEP: manylinux1

[Alexander Walters]

Isnt the entire point of using centos 5 to use an ancient toolchain?

On 1/26/2016 06:44, Antoine Pitrou wrote:

On Tue, 26 Jan 2016 20:36:26 +1000
Nick Coghlan  wrote:

If I understand the problem correctly, the CentOS 5 gcc toolchain is
old enough that it simply doesn't emit the info libabigail needs in
order to work.

If you build on CentOS 5, you certainly want to use the RH developer
toolset 2 which gives you a modern-ish toolchain (gcc 4.8.2, IIRC).

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Non English Speaking Users of PyPI - I need Help!

[Alexander Walters]

How...does the client side text interact with screen readers?  Is that 
an issue?  It sounds like an odd thing to do in the first place...


On 1/26/2016 12:16, Donald Stufft wrote:

Hello!

As many of you are aware there has been an effort to replace the current PyPI 
with a new, improved PyPI. This project has been codenamed Warehouse and has 
been progressing nicely. However we’ve run into a bit of an issue when deciding 
what to support that we’re not feeling super qualified to make an informed 
decision on.

The new PyPI is going to support translated content (for the UI elements, not 
for what people upload to there), although we will not launch with any 
translations actually added besides English. Currently the translation engine 
we’re using (l20n.js) does not support anything but “Evergreen” browsers 
(browsers that constantly and automatically update) which means we don’t have 
support for older versions of IE. My question to anyone who is, or is familiar 
with places where English isn’t the native language, how big of a deal is this 
if we only support newer browsers for translations?

If you can weigh in on the issue for this 
(https://github.com/pypa/warehouse/issues/881) that would be great! If you know 
someone who might have a good insight, please pass this along to them as well.

Thanks!

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] heads-up on a plot to bring linux wheels to pypi

[Alexander Walters]

On 1/14/2016 06:13, Nathaniel Smith wrote:

On Thu, Jan 14, 2016 at 2:19 AM, Nick Coghlan  wrote:

On 14 January 2016 at 20:12, Nick Coghlan  wrote:

On 14 January 2016 at 15:55, Nathaniel Smith  wrote:

- build some test wheels
- write a proper PEP
- convince pip and pypi maintainers that this is a good idea ;-)

While I've historically advocated against the idea of defining our own
"Linux platform ABI" subset, the fact that Enthought and Continuum are
successfully distributing pre-built binaries through the simple "use
CentOS 5.11" approach seems promising.

In terms of non-scientific packages, the main group I'd suggest
getting in touch with is pycryptography, as we'll probably want to
baseline a more recent version of OpenSSL than the one in CentOS 5.11.

Ah, looking at https://github.com/manylinux/auditwheel, I see anything
linking to OpenSSL would fail the platform audit, at least for the
current draft policy. That also seems like a potentially reasonable
approach (although it could lead to complaints about "Why doesn't
project  offer a wheel file?")

Yeah, it's very unfortunate, that's exactly the library that you'd
like to be able to depend on, so we checked specifically. But it turns
out that openssl has broken ABI over the relevant time-period, so
there's no choice, you can't rely on the system version and have to
statically link :-(.

Though I guess this is no worse than than if you want to distribute a
wheel that needs openssl on Windows.

-n

Theoretically you can statically link openssl on windows, or otherwise 
include it.  An odd benefit (in this case, only) of an operating system 
that includes nothing is a culture of vendoring everything.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Alexander Walters]

I perhaps can support added dialogs to IDLE to manage packages (having 
it shell out to pip, if no api is forthcoming), but I don't think I can 
support having the repl inside of IDLE intercept pip's command line 
syntax and do anything OTHER than giving a better error message.


On 11/14/2015 06:37, Oscar Benjamin wrote:



On 14 Nov 2015 11:12, "Paul Moore" > wrote:

>
> On 13 November 2015 at 23:38, Nathaniel Smith > wrote:

> > But details of R's execution model make this easier to do.
>
> Indeed. I don't know how R works, but Python's module caching
> behaviour would mean this would be full of surprising and confusing
> corner cases ("I upgraded but I'm still getting the old version" being
> the simplest and most obvious one).
>
> > Maybe it could be supported for the special case of installing new 
packages with no upgrades


Maybe it could prompt the user that the interpreter will need to be 
restarted for the changes to take effect. IDLE runs the interactive 
interpreter in a separate process so it could restart the subprocess 
without closing the GUI (after prompting the user with a 
restart/continue dialogue).


I'm not sure if the standard interpreter would be able to relaunch 
itself but it could at least exit and tell the user to restart (after 
a yes/no question in the terminal). The command could also be limited 
to the when the interpreter is in interactive mode.


How it works in the terminal is less important to me than how it works 
in IDLE though; being able to teach how to use Python through IDLE 
(deferring discussion of terminals etc) is useful for introductory 
programming classes.


--
Oscar



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Alexander Walters]

import pip
pip.install(PACKAGESPEC)

something like that?

On 11/13/2015 12:42, Chris Barker wrote:
On Fri, Nov 6, 2015 at 8:06 AM, Paul Moore > wrote:


That's the correct command, but you need to run it from the Windows
command prompt, not from within IDLE.


Now that we are talking about how to invoke the installer on other 
threads...


This is NOT the least bit a rare mistake for newbies. Maybe we should 
have a way to install right from inside the python REPL.


That would certainly clear up the "which python is this going to get 
installed into" problem.


-CHB






--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Alexander Walters]

While I like the concept of calling pip via an api (and let me pat 
myself on the back for suggesting it in the first place in this thread), 
I honestly think that if it is something that is allowed, it should be 
implemented with a fair bit of guards.  It would probably end up being a 
power-user feature - something to help manage deployments in some tricky 
environments - than a newbie feature.


Python is an IDE-less language, and I say this knowing full well what 
IDLE is.  We don't default to eclipse like java does, or Visual Studio 
like .NET languages (and C(++) on windows).  We do not have the default 
tooling in place to avoid using the command line. Learning the command 
line is a vital skill for newbies.


Now, while this thread may or may not be about Windows newbies 
specifically, I do not tend to see this brought up for *nix newbies.  Is 
this because we assume that a *nix user will have to know the command 
line?  or that they are inherently power users?  If it is the latter, 
then I need to say that being a programmer also means being a power 
user.  We should guide new users to power user tools (the command line, 
powershell, etc), instead of trying to bend python to regular users who 
will eventually be power users anyways.


I guess I am suggesting maybe we try and find a way to shallow the 
learning curve into using the command line than to just implement 
commands in the repl itself.


all that said, IDLE could be tooled to intercept the syntax 'pip install 
foo' and print a more helpful message.


On 11/13/2015 15:27, Chris Barker wrote:



On Fri, Nov 13, 2015 at 12:09 PM, Nathaniel Smith <n...@pobox.com 
<mailto:n...@pobox.com>> wrote:


On Nov 13, 2015 12:00 PM, "Alexander Walters"
<tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>> wrote:
>
> import pip
> pip.install(PACKAGESPEC)
>
> something like that?

This would be extremely handy if it could be made to work
reliably... But I'm skeptical about whether it can be made to work
reliably. Consider all the fun things that could happen once you
start upgrading packages while python is running, and might e.g.
have half of an upgraded package already loaded into memory. It's
like the reloading problem but even more so.

indeed -- does seem risky.

also, if were are in fantasy land, and want to be really newbie 
friendly, a new built in:


pip.install(PACKAGESPEC)

with no import required

-CHB


--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Which Build Distribution Formats do exist?

[Alexander Walters]

On 11/4/2015 15:13, Thomas Güttler wrote:

 From http://python-packaging-user-guide.readthedocs.org/en/latest/glossary/


Egg
A Built Distribution format introduced by setuptools, which is being replaced 
by Wheel.

Which other Built Distribution formats do exist beside egg and wheel?

Regards,
   Thomas Güttler



EXE installers for windows.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Alexander Walters]

On 8/14/2015 16:16, Chris Barker wrote:
On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower steve.do...@python.org 
mailto:steve.do...@python.org wrote:


There was discussion about an incompatible_with metadata item at
one point. Could numpy include {incompatible_with: scipyx.y} in
such a release? Or would that not be possible.


circular dependency hell! scipy depends on numpy, not teh other way 
around -- so it needs to be clear which version of numpy a given 
version of scipy depends on.


-CHB

I think a better spelling of that would be something along the lines of 
'abi_version' - listing all the packages your new version of your module 
breaks... is a long list.


- Alex W.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip/warehouse feature idea: help needed

[Alexander Walters]

On 4/12/2015 21:08, Nick Coghlan wrote:


Hence the idea of making the feature accessible through the command 
line clients, not just the web service.



For the love of...

Can we get packaging fixed before we start jamming crap onto the tools?  
Enough already.   No.  Just No.  Never.  Stop.  Just stop. No.  As a  
user of these things, just stop right there.


I personally believe so, yes - sustaining software over the long term 
is expensive in people's time, but it's often something we take for 
granted. The specific example Guido brought up in his keynote was the 
challenge of communicating a project's openness to Python 3 porting 
assistance.


In the current user experience, if a project we use stops getting 
updated, resentment at the lack of updates is a more likely reaction 
for most of us than concern for whether or not the maintainer is OK.


Again, great idea.  Does not need to be on the index.  Does not even 
need to be on the same infrastructure as the index.  I can think of at 
least four other places on the web where it will be better suited.  If 
the PSF wants to take charge of that, then super.  Put it next to the 
job board.


But if you really want to solve the problem through the index, just make 
the link to SCM repos mandatory, and thats all you have to, and even 
should, do.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip/warehouse feature idea: help needed

[Alexander Walters]

Is the package index really the best place to put this?  This is a very 
social-networking feature for the authoritative repository of just about 
all the third party module, and it feels like either it could corrupt 
the 'sanctity' of the repository (in the absolute worst case), or simply 
be totally ineffective because we all only see the cheese shop through 
pip and twin (in the best case).


I am not saying the PSF shouldn't do this, but is pypi REALLY the best 
part of python.org to put it?


On 4/11/2015 10:46, Nick Coghlan wrote:


Guido mentioned in his PyCon keynote this morning that we don't 
currently have a great way for package authors to ask for help from 
their user base.


It occurred to me that it could be useful to have a Help needed 
feature on PyPI (after the Warehouse migration) where package 
maintainers could register requests for assistance, such as:


* looking for new maintainers
* requests for help with Python 3 support
* links to specific issues a maintainer would like help with
* links to donation pages (including links to Patreon, Gratipay, etc)
* links to crowdfunding campaigns for specific new features
* links to CVs/LinkedIn if folks are looking for work

Given a requirements.txt file, pip could then gain a help-needed 
command that pulled the help needed entries for the named projects.


The general idea would be to provide a direct channel from project 
maintainers that may need help to their users who may be in a position 
to provide that help. It wouldn't need to be too complicated, just a 
Markdown field that maintainers could edit.


In some cases, software is backed by folks that already have a 
sustainable support model. For these it could be nice if the Markdown 
field could be used to say Help not needed, and give credit to the 
people or orgs supporting them.


It's not something we can do anything about until after the Warehouse 
migration, but I figured I'd mention it while I was thinking about it :)


Cheers,
Nick.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig