On 27 Sep 2014 14:19, "Chris Barker" wrote:
>
> All this is also making me think that virtualenv and friends is the real
solution to user installed packages anyway.
The main use case that doesn't cover is system scripting on Linux, where
you may want access to all the platform specific libraries.
On 2014-09-27, at 00:11 , Cameron Simpson wrote:
> On 26Sep2014 13:16, Antoine Pitrou wrote:
>> On Fri, 26 Sep 2014 01:10:53 -0700
>> Hasan Diwan wrote:
>>> On 26 September 2014 00:28, Matěj Cepl wrote:
>>> > Where does your faith that other /bin/sh implementations (dash,
>>> > busybox, etc.)
On 27 September 2014 06:08, Terry Reedy wrote:
> Pip on Windows should act like a normal Windows program. If I install
> Python for all users, I expect pipped packages to be installed for all users
> too, unless I specify otherwise. If installation (for all users) requires
> admin privileges, I
On Fri, 26 Sep 2014 18:01:31 +
Steve Dower wrote:
> Hi all,
>
> (This is advance notice since people on this list will be interested.
> Official announcements are coming when setuptools makes their next release.)
When you mention "setuptools", do you imply it doesn't work with plain
distuti
On 27 September 2014 22:12, Antoine Pitrou wrote:
> On Fri, 26 Sep 2014 18:01:31 +
> Steve Dower wrote:
>> Hi all,
>>
>> (This is advance notice since people on this list will be interested.
>> Official announcements are coming when setuptools makes their next release.)
>
> When you mention
On 27 September 2014 14:01, Nick Coghlan wrote:
> I personally believe we should treat handling both this and the SDK
> compilers properly as a platform-enablement bug for distutils and
> ensure they work properly with the currently maintained branches
> (including 2.7).
+1
__
On 26.09.2014 20:01, Steve Dower wrote:
> Hi all,
>
> (This is advance notice since people on this list will be interested.
> Official announcements are coming when setuptools makes their next release.)
>
> Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9).
> We've produ
It'll help with the numerical stack, but only a little. The devs involved have
largely figured it out already and I can't provide a good Fortran compiler or
BLAS library, which is what they need.
It'll be much more valuable for the small packages that have one vital C
extension - currently thos
On Sat, 27 Sep 2014 14:10:48 +0100
Paul Moore wrote:
> On 27 September 2014 14:01, Nick Coghlan wrote:
> > I personally believe we should treat handling both this and the SDK
> > compilers properly as a platform-enablement bug for distutils and
> > ensure they work properly with the currently mai
Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but
"update Python" is a big/impossible ask for a lot of people, whereas "update
setuptools" is easy and also covers Python 2.6 and <3.3.
The compiler installer can't set the keys that distutils looks for without
losing the
Christian Heimes wrote:
> Is it possible to compile extensions from Python's numerical stack such
> as NumPy, SciPy and SciKit, too?
The official NumPy installer is currently built with VC9, so probably yes.
Other parts of the SciPy stack needs a Fortran compiler as well, so those
might be more
Steve Dower wrote:
> It'll help with the numerical stack, but only a little. The devs involved
> have largely figured it out already and I can't provide a good Fortran
> compiler or BLAS library, which is what they need.
We finally have a MinGW based toolchain that can be used. Making sure it
was
The SDK compilers are not easily fixable (I've tried). The installation is
basically corrupt as far as the non-x86 compilers are concerned.
The package we just put out is exactly the same files as the SDK with those
issues fixed. There's no reason to encourage the SDK at all now (which was the
13 matches
Mail list logo
