Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Chris Warrick]

On 9 August 2017 at 23:15, Steven D'Aprano  wrote:
> On Tue, Aug 08, 2017 at 12:56:56PM +0200, Chris Warrick wrote:
>
>> While setuptools is not officially part of the stdlib,
>
> This is the critical factor. How can you use *by default* something that
> is *NOT* supplied by default?
>
> Obviously you cannot. It is physically impossible.


The problem with setuptools (and pip) is that they are not first-party
stdlib members, but they are not third-party packages either. They’re
somewhere in between. They have been blessed by the core developers.
And yes, setuptools might be in all the places you mentioned:

> But this does NOT hold for everyone, possibly not even for the majority
> of Python users. For example:
>
> - students using their school's computers;
>
> - corporate and government users using a SOE (Standard Operating
>   Environment);
>
> - people using a system where, for policy reasons, only the
>   standard library is permitted.

* If those computers run Windows (as they often do) and run a recent
Python version (3.4 or newer/2.7.9 or newer), setuptools will be
installed, unless the IT people explicitly disabled ensurepip.
* On macOS, setuptools will be installed if they’re using the system
Python, the python.org installers (which are not uninstallable), or
Python from Homebrew. The last two also have pip, and system Python
has ensurepip.
* On Linux, setuptools/pip is likely to be there, but it’s not
required in all distributions. (Fedora mandates setuptools; Debian
even rips out ensurepip by default and hides it in python3-venv
because reasons…)

If the users are meant to install Python packages, their system
administrators would take care of that — either by setting up
setuptools/pip and perhaps virtualenv, or taking install requests from
users. If users are not supposed to be running setuptools/pip, they
probably shouldn’t, but they can still install it from ensurepip or
downloading get-pip.py.

> I've worked in places where installing unauthorized software was a
> firing offence.

Those people don’t need setuptools. Those people should not be using
distutils either. They might not even be allowed to download packages
and run __main__.py without installation.

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[eryk sun]

On Wed, Aug 9, 2017 at 11:32 PM, Alan Gauld via Tutor  wrote:
> On 09/08/17 22:15, Steven D'Aprano wrote:
>>
>> This is the critical factor. How can you use *by default* something that
>> is *NOT* supplied by default?
>
> I have to agree with Steven here. Any mature language should
> ship with all the tools needed to create and distribute a
> finished program. It is to Python's shame that it currently
> fails that test because the recommended distribution framework
> is not part of the standard language package. (and the irony
> is that the tool for installing the recommended format (pip)
> is in the standard library. You can download other peoples
> stuff but you can't make your own in the same format.
> That's bad.

The standard library has ensurepip [1] to bootstrap bundled wheels for
pip and setuptools, which in turn vendor other packages such as
distlib. The wheels are already there, unless the distro or IT
department has removed them. (They're distributed with the official
Windows installers, at least.) If you want the legal details, you
could ask on the pypa-dev list [2]. I'm sure Nick Coghlan or Donald
Stufft would be happy to clarify the situation.

[1]: https://github.com/python/cpython/tree/v3.6.2/Lib/ensurepip
[2]: https://groups.google.com/forum/#!forum/pypa-dev
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Alan Gauld via Tutor]

On 09/08/17 22:15, Steven D'Aprano wrote:
> On Tue, Aug 08, 2017 at 12:56:56PM +0200, Chris Warrick wrote:
> 
>> While setuptools is not officially part of the stdlib,
> 
> This is the critical factor. How can you use *by default* something that 
> is *NOT* supplied by default?

I have to agree with Steven here. Any mature language should
ship with all the tools needed to create and distribute a
finished program. It is to Python's shame that it currently
fails that test because the recommended distribution framework
is not part of the standard language package. (and the irony
is that the tool for installing the recommended format (pip)
is in the standard library. You can download other peoples
stuff but you can't make your own in the same format.
That's bad.

I hope that this is remedied soon, but for the moment Python
is horribly at odds with itself - enough to disqualify it
from use in many organisations.

Any default solution must be available by default.
It doesn't matter how many people recommend another
solution, if it isn't there it can't be used, and
therefore, can't be the default.

Sadly there seem to be many in the Python community who
do not understand the seriousness of this limitation
in terms of Python's adoption. Because they can access
it they assume everyone can. It's not true, and the further
up the Fortune 500 tree you climb the more that is the case.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Steven D'Aprano]

On Tue, Aug 08, 2017 at 12:56:56PM +0200, Chris Warrick wrote:

> While setuptools is not officially part of the stdlib,

This is the critical factor. How can you use *by default* something that 
is *NOT* supplied by default?

Obviously you cannot. It is physically impossible.


> it *is*
> recommended by the official documentation, the dev team, and it’s
> available pretty much everywhere.

Maybe if your concept of "everywhere" is limited to the subset of Python 
users who have a Linux distro and the permission (both the computer 
privileges and the legal authority) to install software on the computer 
they are using.

But this does NOT hold for everyone, possibly not even for the majority 
of Python users. For example: 

- students using their school's computers;

- corporate and government users using a SOE (Standard Operating
  Environment);

- people using a system where, for policy reasons, only the 
  standard library is permitted.

(E.g. they have their software audited for compliance with licencing and 
malware, the std lib has been audited but third party libraries have 
not. It might take literally months to get permission to install even a 
simple third party library.)

I've worked in places where installing unauthorized software was a 
firing offence.


> setuptools can’t be in stdlib,
> because it’s moving too fast for stdlib to keep up.

The reason doesn't matter. What matters is that it isn't available by 
default, so it cannot be the default.


> Look here: http://pythonwheels.com/ — 254 of the top 360 packages on
> PyPI use wheels. It means that at least that many use setuptools;
> sometimes with a distutils fallback, but often without one. Moreover,
> many of the packages without wheels use setuptools as well.

All this tells me is that many third party packages choose the 
*convenient* choice, not the *default* choice.

That is their right, of course. Nobody says otherwise.

And of course the sort of users who cannot install setuptools likewise 
cannot install their package, so the developers might not care about 
people without setuptools. But that hardly makes it the *default*. It 
just makes it the more popular option.


> The sane default choice is entry_points.

Only if your definition of "sane" or "default" is different from mine.



-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Chris Warrick]

On 8 August 2017 at 03:30, Ben Finney  wrote:
> Thomas Güttler  writes:
>
>> Why is "the sane default is 'use console_scripts entry-point in
>> setup.py'" not a good answer?
>
> Because third-party Setuptools is required for entry points, which means
> entry points cannot be a default choice.
>
> It may well be a good choice for many cases. But that's a different
> matter from it being a good *default* choice; it can only be a default
> choice if it's in the standard library.

While setuptools is not officially part of the stdlib, it *is*
recommended by the official documentation, the dev team, and it’s
available pretty much everywhere. setuptools can’t be in stdlib,
because it’s moving too fast for stdlib to keep up.

Look here: http://pythonwheels.com/ — 254 of the top 360 packages on
PyPI use wheels. It means that at least that many use setuptools;
sometimes with a distutils fallback, but often without one. Moreover,
many of the packages without wheels use setuptools as well.

The sane default choice is entry_points.

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Ben Finney]

Thomas Güttler  writes:

> Why is "the sane default is 'use console_scripts entry-point in
> setup.py'" not a good answer?

Because third-party Setuptools is required for entry points, which means
entry points cannot be a default choice.

It may well be a good choice for many cases. But that's a different
matter from it being a good *default* choice; it can only be a default
choice if it's in the standard library.

-- 
 \   “The best in us does not require the worst in us: Our love of |
  `\ other human beings does not need to be nurtured by delusion.” |
_o__) —Sam Harris, at _Beyond Belief 2006_ |
Ben Finney

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Thomas Güttler]

Am 05.08.2017 um 06:14 schrieb Ben Finney:

Thomas Güttler  writes:


The underlaying question is: Imangine you are a newcomer.


A newcomer is in a tough position when it comes to packaging and
distributing Python code, especially the command-line programs.

There has been significant progress on this in recent years. The
Setuptools third-party library is a lot saner, the inclusion of ‘pip’ in
standard installs makes it much broader in scope.

But *not* in the standard library today, it's true.


You need a guide like 'if unsure do x'. With other words: What is the
sane default choice?


There isn't a good answer to that question, today.

The best answer today is: Read the guides from the Python Packaging
Authority, and stay abreast of developments because this continues to
change.

Maybe eventually the ongoing work of the PyPA will be settled enough
that it can update the standard library Distutils. But not today.



You say that there isn't a good answer to that question, today.

For me the question was: setup.py "script" vs "console_scripts" ?

I found this: 
https://packaging.python.org/tutorials/distributing-packages/#console-scripts

You say that there isn't a good answer to that question, today.

I can't follow.

Why is "the sane default is 'use console_scripts entry-point in setup.py'" not 
a good answer?

Regards,
  Thomas Güttler



--
Thomas Guettler http://www.thomas-guettler.de/
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Ben Finney]

Thomas Güttler  writes:

> The underlaying question is: Imangine you are a newcomer.

A newcomer is in a tough position when it comes to packaging and
distributing Python code, especially the command-line programs.

There has been significant progress on this in recent years. The
Setuptools third-party library is a lot saner, the inclusion of ‘pip’ in
standard installs makes it much broader in scope.

But *not* in the standard library today, it's true.

> You need a guide like 'if unsure do x'. With other words: What is the
> sane default choice?

There isn't a good answer to that question, today.

The best answer today is: Read the guides from the Python Packaging
Authority, and stay abreast of developments because this continues to
change.

Maybe eventually the ongoing work of the PyPA will be settled enough
that it can update the standard library Distutils. But not today.

-- 
 \  “Nothing is more sacred than the facts.” —Sam Harris, _The End |
  `\   of Faith_, 2004 |
_o__)  |
Ben Finney

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Chris Warrick]

On 4 August 2017 at 12:15, Thomas Güttler  wrote:
> Chris wrote "Simple: `scripts` are legacy."
>
> You say it is the standard, and console_scripts is from a third party.
>
> For me "legacy" sound like "don't go this old way".
>
> For me "third party" sounds like "don't go this way, stick to the standard".
>
> I feel stupid since I have no clue.

The official docs recommend distutils:

https://docs.python.org/2/library/distutils.html

> Most Python users will not want to use this module directly, but instead use 
> the cross-version tools maintained by the Python Packaging Authority. In 
> particular, setuptools is an enhanced alternative to distutils that provides:
> [snip]
> * the ability to declare project “entry points”, which can be used as the 
> basis for application plugin systems
> * the ability to automatically generate Windows command line executables at 
> installation time rather than needing to prebuild them

And, as eryk sun mentioned, recent Python 2.7 and 3.4 versions ship
setuptools and pip, via the ensurepip module.

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[eryk sun]

On Fri, Aug 4, 2017 at 10:15 AM, Thomas Güttler
 wrote:
> Am 04.08.2017 um 02:50 schrieb Ben Finney:
>
>> Because Distutils implements only ‘scripts’, and that's not capable
>> enough for what people need so Setuptools implements entry points.
>>
>> In other words: One of them is in the standard library and does
>> something; the other is third-party and can do more.
>>
>> That answers why there are two. But maybe you wanted to ask some
>> underlying question?
>
> The underlaying question is: Imangine you are a newcomer. And there
> are two more choices. You need a guide like 'if unsure do x'. With
> other words: What is the sane default choice?

A newcomer should simply check for __name__ == "__main__". Learning
about packaging comes later.

> Chris wrote "Simple: `scripts` are legacy."
>
> You say it is the standard, and console_scripts is from a third party.

console_scripts and gui_scripts are installed by setuptools and pip,
which are developed under the umbrella of the Python Packaging
Authority [1]. The standard library also has the ensurepip [2] module
to install pip and setuptools. As third-party packages go, they're as
close to being 'standard' as you can get.

> For me "legacy" sound like "don't go this old way".

Legacy scripts aren't automatically created as console or GUI
executables when installed on Windows. Often Windows users associate
.py scripts with an editor, in which case legacy scripts aren't
executable from PATH, i.e. they have to be run as `python
legacy_script.py`, for example.

[1]: https://www.pypa.io
[2]: https://docs.python.org/3/library/ensurepip
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Thomas Güttler]

Am 04.08.2017 um 02:50 schrieb Ben Finney:

Thomas Güttler  writes:


Why are there two ways: "script" vs "console_scripts entry-point"?


Because Distutils implements only ‘scripts’, and that's not capable
enough for what people need so Setuptools implements entry points.

In other words: One of them is in the standard library and does
something; the other is third-party and can do more.

That answers why there are two. But maybe you wanted to ask some
underlying question?


The underlaying question is: Imangine you are a newcomer. And there
are two more choices. You need a guide like 'if unsure do x'. With
other words: What is the sane default choice?

Chris wrote "Simple: `scripts` are legacy."

You say it is the standard, and console_scripts is from a third party.

For me "legacy" sound like "don't go this old way".

For me "third party" sounds like "don't go this way, stick to the standard".

I feel stupid since I have no clue.

Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[eryk sun]

On Thu, Aug 3, 2017 at 4:22 PM, Chris Warrick  wrote:
>
> Simple: `scripts` are legacy. `entry_points` are the new thing.
> There’s also a third approach: gui_scripts entry_points, which work
> the same way on Linux/*nix, but on Windows, it means that running your
> script by opening the created .exe files does not show a console
> window. Note that stdout/stderr do not work in that mode under
> Windows, which can lead to spurious application crashes.  (GUI-only
> processes cannot use stdout/stderr because they don’t have a console
> attached)

A Windows GUI executable doesn't automatically inherit or create a
console for standard I/O. (It has to manually call AttachConsole or
AllocConsole.) But it does automatically inherit the standard handle
values from the parent process (just the integer values, not the
handles themselves). If these handles are inheritable and the child is
created with handle inheritance, then standard I/O will work. For
example:

C:\Temp>echo spam | pythonw -c print(input()) >out.txt 2>&1
C:\Temp>type out.txt
spam

In the above example pythonw.exe is a GUI executable. The example
reads "spam" from stdin and prints it to stdout, which is redirected
to a file named "out.txt". For those who don't know, `>out.txt` is
shell syntax to redirect stdout to "out.txt", and `2>&1` redirects
stderr (2) to stdout (1).
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Ben Finney]

Thomas Güttler  writes:

> Why are there two ways: "script" vs "console_scripts entry-point"?

Because Distutils implements only ‘scripts’, and that's not capable
enough for what people need so Setuptools implements entry points.

In other words: One of them is in the standard library and does
something; the other is third-party and can do more.

That answers why there are two. But maybe you wanted to ask some
underlying question?

-- 
 \   “It ain't so much the things we don't know that get us in |
  `\trouble. It's the things we know that ain't so.” —Artemus Ward |
_o__) (1834–1867), U.S. journalist |
Ben Finney

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

[Chris Warrick]

On 3 August 2017 at 09:52, Thomas Güttler  wrote:
>
>
> Am 02.08.2017 um 18:06 schrieb Wolfgang Maier:
>>
>> On 08/02/2017 04:57 PM, Steven D'Aprano wrote:
>>>
>>> On Wed, Aug 02, 2017 at 10:48:39PM +1000, Ben Finney wrote:

 Thomas Güttler  writes:

> Maybe I am doing something wrong.  I was proud because I did use
> “console_scripts” entry points.


 Did someone lead you to believe it was wrong? Setuptools console_scripts
 entry points are a good tool.

 My point was that it is an *advanced* tool, difficult to use and also
 difficult to explain because the concepts are advanced.
>>>
>>>
>>> Can you explain the use-case for when somebody might want to use
>>> console_scripts entry points?
>>>
>>> I have a module with a main() function and an "if __name__ == ..."
>>> guard. Under what circumstances is that not sufficient, and I would want
>>> console_scripts?
>>>
>>
>> If you install things using pip/setuptools and have defined a
>> console_scripts entry point for it, then the corresponding wrapper
>> script will be installed in whatever is considered the scripts directory
>> at install time on that machine. With a bit of luck the entry point will
>> thus be executable directly without any end-user intervention (like
>> adding folders to $PATH and chmodding files).
>> Personally, I always found it straightforward to write the wrapper
>> script myself, then define this as a 'scripts' file in the package
>> layout of my setup.py, but people's MMV.
>
>
>
> I was not aware of "scripts" in setup.py. But I found docs:
>
>   http://python-packaging.readthedocs.io/en/latest/command-line-scripts.html
>
> Why are there two ways: "script" vs "console_scripts entry-point"?

Simple: `scripts` are legacy. `entry_points` are the new thing.
There’s also a third approach: gui_scripts entry_points, which work
the same way on Linux/*nix, but on Windows, it means that running your
script by opening the created .exe files does not show a console
window. Note that stdout/stderr do not work in that mode under
Windows, which can lead to spurious application crashes.  (GUI-only
processes cannot use stdout/stderr because they don’t have a console
attached)

I’ll take the liberty to link my (better) blog post about this:
https://chriswarrick.com/blog/2014/09/15/python-apps-the-right-way-entry_points-and-scripts/

-- 
Chris Warrick 
PGP: 5EAAEA16
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor