Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

2014-10-30 Thread Chris Angelico 
On Thu, Oct 30, 2014 at 6:34 AM, Glenn Linderman  wrote:
> (I'm actually not sure if *nix package managers allow multiple repositories
> or not, but from the way people talk about them, it always sounds like a
> "distribution" also provides "a repository" of additional packages).

I'm fairly sure they all do. Certainly with apt (the Debian package
manager), it's common to add additional repositories; for instance,
PostgreSQL can be obtained either from the default Debian repos or
from Postgres's own hosting (which usually has more versions
available). A distribution will always provide a repository, and there
are plenty of distros that provide only a small repo and chain to
upstream for most packages - for instance AntiX has its own, and then
pulls in debian.org and a few others. Adding a local-network repo is
fairly straight-forward.

Most likely, OneGet won't replace pip/PyPI, any more than apt or yum
does; but it may be worth having Python itself available that way.
That might simply mean having someone package up Python and put it on
an appropriate server, or maybe python.org could end up hosting a
repo. I've no idea what "trusted" will mean; in the case of apt, any
sysadmin can deem any repo to be trusted (by importing its key), but
this might be more along the lines of "only curated packages" or
something.

To what extent will Windows 10 users expect all their software to come
via OneGet? That's the question.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of C compilers for Python on Windows

2014-10-30 Thread R. David Murray 
On Wed, 29 Oct 2014 23:33:06 -0400, Terry Reedy  wrote:
> On 10/29/2014 4:05 PM, Paul Moore wrote:
> > On 29 October 2014 15:31, Nathaniel Smith  wrote:
> >>> You can use Express editions of Visual Studio.
> >>
> >> IIUC, the express edition compilers are 32-bit only, and what you actually
> >> want are the "SDK compilers":
> >> https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows
> >>
> >> These are freely downloadable by anyone, no msdn subscription required, but
> >> only if you know where to find them!
> >>
> >> AFAICT the main obstacle to using MSVC to build python extensions (assuming
> >> it can handle your code at all) is not anything technical, but rather that
> >> there's no clear and correct tutorial on how to do it, and lots of 
> >> confusion
> >> and misinformation circulating.
> >
> > Would it help if I wrote a document explaining how to set up the MS
> > compilers (free and paid for) to allow building of Python extensions?
> 
> > There are a few provisos:
> >
> > 1. A lot of it will be pretty trivial: "If you have Vistal Studio
> > (full edition), install it. Done."
> > 2. It will be out of date very fast as the situation for Python 3.5+
> > will be trivial across the board.
> > 3. I don't have anywhere particularly authoritative to host it (maybe
> > the Python Wiki?) and it could easily get lost in the huge swamp of
> > variously outdated, over-complicated, or otherwise alternative
> > documents available. Ideally I'd like someone to suggest an "official"
> > location I could use.
> 
> There is already a section in the devguide for building Python itself, 
> with mostly the same info, except it may not be up to date.
> 
> > I don't want to do this if it won't be useful, as it'll take me a bit
> > of effort to confirm the process for the only non-trivial scenario
> > (64-bit Python 3.3/3.4 with free tools). But if people think it would
> > help, that's fine, I volunteer.
> 
> The devguide needs to be kept up to date.  If you open a tracker issue, 
> put me as nosy to review and commit.

The devguide is about building python itself.  Paul is talking about
building extensions.  That should go in the packaging docs.  I don't
*think* Paul is volunteering to explain how to build python itself,
that's pretty much our job :)

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

2014-10-30 Thread Martin v. Löwis 
Am 29.10.14 20:34, schrieb Glenn Linderman:
> New package manager from M$... article here
> .

I've looked at it, but only by reading its code, not trying it out.
Some notes.

First, what is Chocolatey? It's a PowerShell library, and a package
infrastructure. A Chocolatey package is a PowerShell script that
installs a piece of software on the system. The software itself comes
in a different format. There are installer helpers for exe, msi and msu,
Python packages (running setup.py), Ruby packages, etc. There appears to
be a notion of dependencies also.

OneGet is similar; it is also a PowerShell library. It has the notion
of "providers", which are classes that can make a package installed.
There is the ARP provider (Add-Remove-Programs), which can report that
a package is already installed. There is the MSI provider, which can
install an MSI file that is already on disk. And there is the web
provider which can download a file over http. They claim to include
a re-implementation of Chocolatey (meaning that Chocolatey packages
can be installed), however, ISTM that this only supports exe and msi
packages.

I haven't seen anything resembling dependencies in OneGet.

Regards,
Martin



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

2014-10-30 Thread Martin v. Löwis 
> Most likely, OneGet won't replace pip/PyPI, any more than apt or yum
> does; but it may be worth having Python itself available that way.
> That might simply mean having someone package up Python and put it on
> an appropriate server, or maybe python.org could end up hosting a
> repo. 

Python is already available in Chocolatey:

https://chocolatey.org/packages/python

Given that OneGet intends to support Chocolatey as a repository,
it might just work already. All python.org would have to guarantee
is stable URLs for the Python msi files.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

2014-10-30 Thread Steve Dower 
>> Most likely, OneGet won't replace pip/PyPI, any more than apt or yum
>> does; but it may be worth having Python itself available that way.
>> That might simply mean having someone package up Python and put it on
>> an appropriate server, or maybe python.org could end up hosting a
>> repo.
> 
> Python is already available in Chocolatey:
> 
> https://chocolatey.org/packages/python
> 
> Given that OneGet intends to support Chocolatey as a repository, it might just
> work already. All python.org would have to guarantee is stable URLs for the
> Python msi files.

I'd like it if we guarantee stable URLs anyway. The 3.5 installer will have a 
single flag to switch between building a full bundle (~23MB) or a tiny 
downloader (<500KB), but the latter option is only viable if the URLs are 
stable. I can also include options in the downloader for 32/64-bit versions and 
debug symbols, which would really reduce the choices for a user (and yes - the 
entire installer is still automatable and I'll write up docs to go with it for 
sysadmin scenarios).

(I believe that OneGet does support dependencies, since one of the intended 
uses is setting up dev environments. If it gets backported, I'll see about 
setting up a Python build environment in there, unless someone else does it 
first.)

Cheers,
Steve

> Regards,
> Martin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of C compilers for Python on Windows

2014-10-30 Thread Terry Reedy 

On 10/30/2014 8:59 AM, R. David Murray wrote:

On Wed, 29 Oct 2014 23:33:06 -0400, Terry Reedy  wrote:



The devguide needs to be kept up to date.  If you open a tracker issue,
put me as nosy to review and commit.


The devguide is about building python itself.  Paul is talking about
building extensions.  That should go in the packaging docs.  I don't
*think* Paul is volunteering to explain how to build python itself,
that's pretty much our job :)


I was thinking that building Python and extensions used the same tools, 
but then I read that the new compiler for 2.7 was extensions only and 
ditto for something else.  If VC Express 2010 is in a new location, that 
*should* be recorded in the devguide.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

2014-10-30 Thread Glenn Linderman 

On 10/30/2014 7:30 AM, "Martin v. Löwis" wrote:

Most likely, OneGet won't replace pip/PyPI, any more than apt or yum
does; but it may be worth having Python itself available that way.
That might simply mean having someone package up Python and put it on
an appropriate server, or maybe python.org could end up hosting a
repo.

Python is already available in Chocolatey:

https://chocolatey.org/packages/python

Given that OneGet intends to support Chocolatey as a repository,
it might just work already. All python.org would have to guarantee
is stable URLs for the Python msi files.

It might. Thanks for that information.

Poking around the link, I discover a weirdness: the claim that the 
package to install 32-bit Python on 64-bit systems is different than 
installing the 32-bit Python on 32-bit systems. While the instructions 
are explicit on what to do inside the chocolatey environment for all 3 
cases (the third being 64-bit install on 64-bit systems), I'm baffled as 
to why there is a difference, because there isn't when downloading 
32-bit Python from python.org...


And there is a weird reference to chocolatey's -x86 parameter, and the 
explanation seems to be that chocolatey has provision for installing 
32-bit or 64-bit packages on 64-bit systems, but  that the way Python is 
included in chocolatey, that provision can't be used.  Sounds very 
strange, like whoever set this up either didn't understand Python, or 
didn't understand chocolatey, or there is some limitation to the 
chocolatey implementation of 32-bit vs 64-bit packages.


Maybe if I understand chocolatey, this wouldn't seem so weird.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com