On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote:
> it may be possible to define a
> >> standard approach that goes something along the lines of defining a
> >> standard location that (somehow) gets added to the load path, and
> >> interested parties provide DLLs for external dependencies, which
On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote:
> It would buy *me* flexibility to use python.org build of Python, or my
> own builds. And not to have to wait for conda to release a build of a
> new version.
you are perfectly free to make your own conda package of python -- it's not
that hard
Final note after a long thread:
Just like Nick pointed out in his original post (if I read it right) , the
pip vs the conda approach comes down to this:
Do you want to a system to manage the whole stack? or do you want a
system to manage Python packages?
Personally, I think that no matter how
On Fri, Nov 4, 2016 at 11:29 PM, Nick Coghlan wrote:
> If I understand correctly, conda-forge works on the same basic
> principle - reviewing the publishers before granting them publication
> access, rather than defending against arbitrarily malicious code at
> build time.
>
yup -- that's pretty
On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver
wrote:
> Questions:
> 1. Editable installs. The PEP currenly specifies a hook to do an
> editable install (like 'pip install -e' or 'setup.py develop') into a
> given prefix. I don't think that specifying a prefix is sufficient to
> cover '--user'
On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith wrote:
> On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker
> wrote:
>
> > Please, please, let's figure SOMETHING our here - editable installs (or
> > "develop" installs) are a critical tool. Frankly, I don
On Thu, Nov 24, 2016 at 3:10 PM, Paul Moore wrote:
> Honestly, I don't see what's so bad about pth files. They are a
> standard supported Python approach. Maybe setuptools' use of them is
> messy?
exactly.
The fact that setuptools over-uses (abuses?) pth files doesn't mean that
they can't be u
On Mon, Nov 28, 2016 at 10:01 AM, Paul Moore wrote:
> On 28 November 2016 at 17:53, Chris Barker wrote:
> >> Why not just have a single pth file, maintained by the build
> >> tool, for all editable installs?
> >
> > shouldn't that be maintained by the inst
As pointed out by others, there are external groups doing "curating".
conda-forge is one such project, so I'll comment from that perspective:
It's difficult because the definition of compatibility is highly dependent
on
>
> the consumer's environment. For example, C extension compatibility will
On Thu, Dec 15, 2016 at 8:29 PM, Glyph Lefkowitz
wrote:
> At the beginning of your story you mentioned the GUI client - *that* is
> the missing piece ;). I've been saying for years that we need a Python.app
> that lets you easily bootstrap all this stuff: walk you through installing
> C dev tool
On Fri, Dec 16, 2016 at 5:51 AM, Daniel Holth wrote:
> One possibility to consider is that virtualenv itself is a bad idea. Why
> should the Python interpreter executable, rather than the program being
> run, determine the set of packages that is available for import?
>
well, way back when, som
On Wed, Apr 5, 2017 at 6:41 PM, Nick Coghlan wrote:
> PayPal Engineering put together a decent write-up of their path
> towards adopting that model last year:
> https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/
Thanks for that link.
We're a much smaller shop, but have
On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner wrote:
> Chances are, there will be a package or two that you rely on that is not
>> in conda defaults (maintained by Continuum) or currently in conda-forge. So
>> you can pip-install those few -- but what if they aren't on PyPi either? or
>> are hard t
one point:
I probably should have named it something other than /legacy/,
>
yes, it should have -- names matter! and having a "legacy" in teh name when
there is not "modern" or "current", or, indeed, anything else is very
confusing.
pypi.org, might as well get it all done at once. It might be
On Fri, Aug 4, 2017 at 5:42 PM, Lucas Boppre Niehues
wrote:
>
> The long description was originally Markdown, and converted to RST by
> pandoc. I would 100% understand if this conversion triggered some bug.
>
It's a good idea to run docutils on it yourself -- but in any case, broken
RST has alwa
On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore wrote:
> > Suppose you
> > have a frontend like pip that when given a source directory and asked
> > to build a wheel, wants to implement that as:
> > - build sdist
> > - unpack sdist
> > - build wheel from unpacked sdist
>
> ... I'd like to
> poi
On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft wrote:
> Donald, what do you think? IIRC, you were most keen on going
> sdist->wheel where possible, and I don't think you've commented on
> Paul's suggestion yet (apologies if I've overlooked a response).
>
>
> I still think it should, and prefer pi
I've thought for ages that we could transition to a more sane system by
convention:
"your setup.py, after being imported, will have a "setup_params" attribute
that is a dict that can be passed to setup()."
So tools that want metadata, etc. without actually running an install could
do;
import se
g
> sdist->wheel protects the user against the known-to-be-an-issue bug
> that the backend doesn't ensure wheel equivalence.
pip can not protect the user from a poorly written back-end. And it
shouldn't try.
* Chris Barker has pointed out that backends have no reason to support
&g
On Mon, Aug 28, 2017 at 12:50 PM, Paul Moore wrote:
> Me too. At the moment, I only expect two backends of any substance -
> your flit backend and xoviat's setuptools one. But I only know of one
> frontend, namely pip - and talk of projects like tox or twine acting
> as frontends never seems to g
> conda-build doesn't produce or consume wheels. It works by creating a
> clean
> > conda environment and running a shell script to install the python
> package
> > into that environment
To be really clear -- conda build doesn't directly use ANY build/install
system.
All files produced by the i
On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote:
> > As to using pip to build wheels -- there is good reason to do that
> > now, but in s post PEP 517 world, one would call the build system
> > directly to build a wheel-- after all, all pip should be doing is
> > calling the build system anywa
On Thu, Aug 31, 2017 at 9:04 AM, Donald Stufft wrote:
> I'm a bit confused -- are we talking about the backwards compatible
> path to the future -- or the end-game?
>
>
> Pip purposely overrides what setuptools tags the wheel with in order to
> make it extremely specific to the Python it is curre
On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith wrote:
> > Surely the build system should know how to correctly name the wheel it
> builds.
>
> It's probably worth mentioning the specific problem that motivated pip
> to start doing this.
>
> It used to be standard, and is still quite common, fo
On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan wrote:
since it
> doesn't reliably distinguish between "this cached wheel was downloaded
> from a repository" and "this wheel was generated locally with a
> particular version of Python".
It shouldn't have to. sigh.
>
PEP 517 deliberately doesn't l
On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan wrote:
> >> Do the Linux distros use pip to build their packages?
> >
> > Not that I am aware of.
>
> Fedora's build macros for Python projects currently rely on running
> setup.py directly, but we've been considering switching to pip instead
> since 2
Someone on another list indicated that pip installing binary wheels
from PyPi will ONLY work for Windows.
Is that the case? I think it's desperately needed for OS-X as well.
Linux is so diverse that I can't imagine it being useful, but OS-X has
only so many versions, and the python.org OS-X binar
On Fri, Oct 18, 2013 at 6:22 PM, Nick Coghlan wrote:
>> -- it would be very useful if folks could easily
>> get binary wheels for OS-X
>
> We do plan to support it, but the pip devs uncovered a hole in the current
> wheel spec that means it generates the same filename on *nix systems for
> wheels
On Mon, Oct 21, 2013 at 11:52 AM, Donald Stufft wrote:
>> Thanks -- but really? don't OS-X wheels get:
>>
>> macosx_10_6_intel
>>
>> or some such tacked on? Where does that go wrong?
>
> Homebrew, Mac Ports, Fink. That would work OK if nobody ever installed things
> that the system didn't provide
On Tue, Oct 22, 2013 at 1:19 PM, Nick Coghlan wrote:
>> PEP 453 has had most of my attention lately, but my tentative thought has
> been to introduce a relatively freeform "variant" field to the wheel spec.
>
> Windows and Mac OS X would then default to an empty variant, while other
> *nix systems
On Mon, Oct 28, 2013 at 3:50 PM, PJ Eby wrote:
> You could include a dummy extension that does nothing, I suppose. Or
> which controls the building of your actual extensions. Setuptools has
> long supported Pyrex and I think that Cython might also work, i.e.,
> that you could just specify your
On Thu, Oct 31, 2013 at 2:34 PM, Nick Coghlan wrote:
> > For all platforms *except* Windows, wheels are essentially caches --
> > there is no real reason to distribute them via PyPI at all, because OSx
> > and Linux develpoers will have tools to build them from sdists.
>
That's not at all true --
On Thu, Oct 31, 2013 at 9:49 AM, Daniel Holth wrote:
> I'm sure you could build your own broken Windows Python, but who
> bothers?
As long as we are clear that we are talking about a social difference here,
not a technical one...
IMO it pretty much boils down to the fact that on Windows you
>
On Fri, Nov 1, 2013 at 6:59 AM, Paul Moore wrote:
> The key point here is the granularity of the PEP 425 tags used by wheel.
>
> The risk is that a wheel created on another system might declare (via
> its filename) that it is compatible with your system, and then not be,
> causing segfaults or si
On Fri, Nov 1, 2013 at 5:45 PM, Nick Coghlan wrote:
> * the key relevant points about users on Windows and Mac OS X are that
> most (perhaps only many on Mac OS X) tutorials and introductory courses
> will direct them to the binary installers on python.org, and such users
> are highly unlikely to
Is this the right place to discuss UX issues for pip? If not, point to the
right place, if so, read on:
I think pip's usability could be much improved with a little tweaking to
the messages it prints to the console when it does its thing. For instance,
when I do a:
pip install some_package
I get
On Mon, Dec 2, 2013 at 5:22 AM, Nick Coghlan wrote:
> And the conda folks are working on playing nice with virtualenv - I don't
> we'll see a similar offer from Microsoft for MSI any time soon :)
>
nice to know...
> > > a single organisation. Pip (when used normally) communicates with PyPI
> > >
Side note about naming:
I'm no expert, but I'm pretty sure "Anoconda" is a python distribution --
python itself and set of pre-build packages. "conda" is the package manager
that is used by Anoconda -- kind of like rpm is used by RedHat -- conda is
an open-source project, and thus could be used by
On Tue, Dec 3, 2013 at 12:48 AM, Nick Coghlan wrote:
> Because it already works for the scientific stack, and if we don't provide
> any explicit messaging around where conda fits into the distribution
> picture, users are going to remain confused about it for a long time.
>
Do we have to have exp
On Tue, Dec 3, 2013 at 3:50 PM, Marcus Smith wrote:
>
>> umm, why not? you couldn't have a pySide wheel???
>>
>
> just saying that the anaconda index literally has packages for "qt"
> itself, the c++ library.
> http://repo.continuum.io/pkgs/free/linux-64/qt-4.8.5-0.tar.bz2
>
> and it's pyside pac
On Wed, Dec 4, 2013 at 12:56 PM, Ralf Gommers wrote:
> The problem is explaining to people what they want - no one reads docs
> before grabbing a binary.
>
right -- so we want a default "pip install" install that will work for most
people. And I think "works for most people" is far more important
On Thu, Dec 5, 2013 at 5:52 PM, Donald Stufft wrote:
>
> On Dec 5, 2013, at 8:48 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
> > What would really be best is run-time selection of the appropriate lib
> > -- it would solve this problem, an
On Thu, Dec 5, 2013 at 11:21 PM, Ralf Gommers wrote:
> Hmm, taking a compile flag and encoding it in the package layout seems
> like a fundamentally wrong approach.
>
well, it's pretty ugly hack, but sometimes an ugly hack that does the job
is better than nothing.
IIUC, the Intel MKL libs do som
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan wrote:
> >> I created a draft of this new section at
> >>
> https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
>
looks good, thanks!
ONe note:
"""
In particular, bootstrapping conda via ``pip
On Fri, Dec 6, 2013 at 4:33 AM, Nick Coghlan wrote:
> In the absence of the perfect solution (i.e. picking the right variant
> out of no SSE, SSE2, SSE3 automatically), would it be a reasonable
> compromise to standardise on SSE2 as "lowest acceptable common
> denominator"?
>
+1
> Users with n
On Fri, Dec 6, 2013 at 5:06 AM, David Cournapeau wrote:
> As Ralf, I think it is overkill. The problem of SSE vs non SSE is because
> of one library, ATLAS, which as IMO the design flaw of being arch specific.
>
yup -- really designed for the end user to built it themselves
> MKL does not
On Fri, Dec 6, 2013 at 5:16 AM, Thomas Heller wrote:
> Am 06.12.2013 13:22, schrieb Nick Coghlan:
>
> Manipulation of __path__ at runtime usually makes it harder for
>
>> modulefinder to find all the required modules.
>>>
>>
>> Not usually, always. That's why
>> http://docs.python.org/2/library
Just a note here:
the wxWidgets (and thus wxPython, natch) project has a wxStandardPaths
object:
http://docs.wxwidgets.org/trunk/classwx_standard_paths.html
It provides a cross platform way to get, well, the standard paths an
application might need:
GetAppDocumentsDir ()
GetConfigDir ()
GetData
On Sat, Dec 21, 2013 at 2:57 AM, Nick Coghlan wrote:
> compliant daemon like cobblerd as a wheel file - using Python specific
> formats to define the layout of full applications, not just libraries.
>
> I'd generally been resisting the idea of supporting this (since I
> favour interoperating wi
On Mon, Dec 23, 2013 at 1:43 PM, Daniel Holth > Agreed. My biggest concern
with this whole idea is that developers
> > (typically POSIX developers, but it applies equally to all) will
> > *think* they need something like sbin because they are used to the
> > concept from their environment, and so
On Tue, Dec 24, 2013 at 2:28 PM, Nick Coghlan wrote:
> > But that concept doesn't work on all platforms, so we should be careful
> about isolating it.
>
> Encapsulating that assumption is why I think the "gnu" nesting is
> justified. There are layout expectations inherent in the autoconf director
On Mon, Jan 6, 2014 at 12:26 PM, Steve Spicklemire wrote:
> avoid troubling anyone with pesky questions. In that respect I've
> apparently failed, because here comes the question!
>
I think this is a use case that is quite useful for us all to chew on a
bit...
1st -- yes "Anaconda" refers to
On Mon, Jan 6, 2014 at 3:20 PM, Steve Spicklemire wrote:
> Thanks Chris for the detailed reply.
Well, I'm trying to sort out similar issues myself
Right. My impression is/was that python.org/CA/Canopy were all different
> builds of python that were *not* interoperable.
well, in the case
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau wrote:
> We don't use mingw to build packages distributed within canopy (at least
> not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC
> often causes trouble.
>
>
so is Canopy binary-compatible with the python.org builds?
i.e w
What David said, plus:
On Thu, Jan 9, 2014 at 10:43 PM, Steve Spicklemire wrote:
>
>> So, related question: Should the Mac binaries also work with the
>> python.org mac build?
>
>
Not sure what "also" is respect to, but the pyton.org builds are a good
common denominator:
The Apple builds have th
On Thu, Jan 23, 2014 at 12:25 PM, Thomas Heller wrote:
> Did I say this before? I would suggest that numpy develops a way
> where all the SSE binary variations would be installed, and the
> appropriate ones be loaded at runtime, depending on the user's CPU
> capabilities. This would also allow
On Fri, Jan 24, 2014 at 2:18 AM, Nick Coghlan wrote:
> In return, as Paul points out, it becomes substantially easier for people
> that *aren't* wholly invested in the scientific Python stack to try it out
> with their regular tools, rather than having to completely change how they
> work with Py
On Fri, Jan 24, 2014 at 2:40 PM, Paul Moore wrote:
> So no, numpy does not build out of the box. Ah well.
>
Darn -- it used to, and it should. It has shipped for years with an "LAPACK
light", and shouldn't need any fortran. It used to not even look for LAPACK
with a default configuration.
But I
On Sat, Jan 25, 2014 at 4:29 PM, Nick Coghlan wrote:
> To put the "but what if the user doesn't have SSE2 support?" concern in
> context, it should only affect Intel users with CPUs older than a Pentium 4
> (released 2001), and AMD users with a CPU older than an Opteron or Athlon
> 64 (both relea
On Wed, Jan 29, 2014 at 2:04 PM, David Cournapeau wrote:
> I think the SSE issue is a bit of a side discussion: most people who care
> about performance already know how to install numpy. What we care about
> here are people who don't care so much about fast eigenvalue decomposition,
> but want to
On Thu, Mar 6, 2014 at 4:27 PM, MinRK wrote:
> I proposed a patch <https://github.com/pypa/pip/pull/1465> to pip, with
> respect to treatment of the platform tag on OS X, and Chris Barker proposed
> that I bring the discussion here.
>
Note -- there is some more discu
On Fri, Mar 7, 2014 at 9:50 AM, Brian Wickman wrote:
> I've also run into similar issues. What I do with PEX is fudge PEP425
> tags for OS X in order to be more correct:
>
> https://github.com/wickman/commons/blob/wickman/pep425/src/python/twitter/common/python/pep425.py
>
>
> I'd love if some
On Thu, Mar 27, 2014 at 2:23 PM, Nick Coghlan wrote:
> On 28 Mar 2014 05:42, "Daniel Holth" wrote:
> > I became convinced that build was an inherently arbitrary-code
> > process, and not something to be universally handled by a declarative
> > system,
>
> It wasn't an accident that last years Py
Folks,
I'm trying to help figure out how to do binary wheels for a package that
relies on ctypes and a bundles shared lib (dll, .so. etc)
The trick here is that the python code is quite version and platform
independent: py2 and py3, version 2.7 and 3.3+ (I think)
(it's py_enchant, if anyone is i
On Wed, Jun 11, 2014 at 9:09 AM, Daniel Holth wrote:
> This is in the bug tracker already. We need to add the py2-none-arch tags
> etc. to Pip's list.
>
Great, thanks. Is the idea that:
pyenchant-1.6.6-py2.py3-none-macosx_10_6_intel.whl
should have worked? And will in some future version?
-Chr
ut it right after these:
> https://github.com/pypa/pip/blob/develop/pip/pep425tags.py#L78
OK, thanks -- that's going to take some poking around.
Maybe once we have the build actually working, I'll take a look at that.
-Chris
> On Wed, Jun 11, 2014 at 12:32 PM, Chris Barker
On Fri, Jul 25, 2014 at 7:21 AM, Daniel Holth wrote:
> > This kind of thing will require us to implement a flag that tells pip
> > "setup.py cannot install; go through wheel" which is somewhere in the
> > plans..
>
couldn't you write a file called "setup.py", with the core API (i.e
setup.py buil
On Wed, Sep 24, 2014 at 6:55 AM, Paul Moore wrote:
> Thanks for the pointer. (Also thanks to Allen Riddell). I'll take a
> look. Ideally, what I'd like to do is write something up to help
> non-Windows experts get things up and running, so this will be very
> useful.
>
Thanks -- that would be gr
On Wed, Sep 24, 2014 at 11:49 AM, Paul Moore wrote:
> > essentially One platform, and the freely available SDK is ONE compiler
> > environment.
>
> If only that were true :-)
>
> What I've found is:
>
> 1. Different SDKs are needed for Python 2.7 and 3.3+ (the VS2008/VS2010
> split)
>
well, yeah
On Thu, Sep 25, 2014 at 8:15 AM, David Cournapeau
wrote:
> The SDK scripts are indeed a bit broken, but it is possible to detect them
> automatically in a way that is similar to what was done for MSVC 2008.
>
> I know that for a fact because I ported the python distutils MSVC
> detection to scons
On Tue, Sep 30, 2014 at 7:45 AM, Daniel Holth wrote:
> Or you could just create a Python package that only contains the dll,
> and depend on it from your others.
but it won't be on the dll search path.
Paul Moore wrote:
> What you could do is distribute a package containing:
> 1. The dll
> 2
On Wed, Oct 1, 2014 at 9:44 AM, David Genest
wrote:
> - We are merely writing extension modules with third party dependent code
> packaged in a dll. In my mind, this use case is not the exception, and
> would not necessarily warrant the use of a full blown solution like conda.
agreed -- it is n
On Wed, Oct 1, 2014 at 5:44 PM, David Genest
wrote:
> We control our environment and package only what is needed in it. This
> makes a micro system in which everything is controlled and isolated, even
> the global dlls (to the virtual env) I wanted to install.
If that is your use case, you may
On Mon, Oct 27, 2014 at 8:30 AM, Marius Gedminas wrote:
> Many setup.py files fail if you run them when your working directory is
> not the one where the setup.py resides itself. I think you can safely
> rely on that implementation detail.
>
agreed, but if you really wanted to be sure you could
no, wheels should not be required -- encourage, absolutely, but required,
no.
> My experience so far tells me otherwise. Our of 7 or so libraries that I
> tried to convert to wheel files that salt stack depends on only 2 were
> using setuptools, others were using distutils and had sometimes quite
Hi folks,
I'm trying to package up a complex system and would like to do it the
correct, modern way.
In particular, this involves a bunch of compiled extensions, as well as
dependencies on both the scientific "stack" and common Web app packages.
(can you tell I'm building a web service front-end
On Tue, Dec 23, 2014 at 10:37 AM, Donald Stufft wrote:
> I’m going to attempt to read between the lines here a little bit.
>
Thank you -- you did an excellent job of capturing the gestalt of my
confusion !
The “egg” name is heavily overloaded in setuptools. It is used all over the
> place for v
On Tue, Dec 30, 2014 at 2:21 PM, Reinout van Rees
wrote:
> Well, we're in a bit of the same boat here. We make django websites, which
> means pretty much well-behaved setup.py-using pure python stuff.
>
> The websites are heavy users of numpy/scipy/pandas/matplotlib and of the
> geo packages like
On Wed, Dec 31, 2014 at 9:10 AM, Nick Coghlan wrote:
> The problem always existed - it's the longstanding conflict between
> "platform independent, language specific" tooling and "platform specific,
> language independent" tooling.
>
> The former is often preferred on the developer side (since th
stall dependencies, if somethign has to. But develop mode is
very much for developers, you really don't want this handled there.
-Chris
On Wed, Dec 31, 2014 at 9:41 AM, Chris Barker wrote:
> On Wed, Dec 31, 2014 at 9:10 AM, Nick Coghlan wrote:
>
>> The problem always exi
Hi folks,
IIIC, there has been a recent change in the setuptools executable that
is distributed with the Windows installer (and source). This
executable is used as a stub to launch scripts that have been
installed using distutils "scripts" system -- i.e put into
C:\Python27\Scripts, or similar)
T
On Wed, Mar 14, 2012 at 9:17 AM, Paul Moore wrote:
>> It's reasonable to argue that this is only a windows problem.
no -- it's a Mac OS-X problem, too. Indeed, a harder one, due to:
A) The Mac platform now has 4! architectures: PPC, PPC64, x86,
intel64. Granted, PPC is almost dead, PPC64 never s
On Wed, Mar 14, 2012 at 3:05 PM, Zvezdan Petkovic wrote:
>> 1) there are folks that want to do a little python that don't have any
>> experience or interest in the whole C building thing -- and to get the
>> compiler on the Mac, you need to register with Mac Developer
>> connection, then download
> On 14 March 2012 19:04, Tarek Ziadé wrote:
>> Why would someone create a binary release when
>> it's pure Python ?
There are a lot of users (Windows and Mac anyway) that like a nice
point+click installer, and don't know (and shouldn't have to) whether
there is any compiled code in there. It's
frankly, I'd give up n find_packages -- it's not that magic, it's just a
convenience function so you don't need to hand-specify them.
But in this case, you're doing something weird, so I"d just be explicit.
Though what I'd probably really do is make the client and server completely
separate packa
Folks,
I'm having a hard time catching up with this, but maybe a few comments
from someone well outside the trenches will be helpful.
And note that one of use cases I'm now wrestling with is using another
package manager (conda), and setuptools is currently a PITA in that
context.
>> you that "p
For the most part, I think it's all been said. What should and
shouldn't be installed by default is really specific extension
dependent, not much point in speculating.
But a comment or two:
having to type
> "python -m something" rather than just "something" isn't broken, it's
> just an inconve
Maybe I wasn't very clear -- I was addressing what conda might provide in
the context of using conda packages with pip/pipy.
A conda environment provides a great deal more, yes.
system-site-packages may very well be for a different version of the python
interpreter and stdlib.
Isn't that handled
> On Jul 17, 2015, at 1:19 PM, Daniel Holth wrote:
>
> I've recently packaged SDL2 for Windows as a wheel, without any Python code.
> It is a conditional dependency "if Windows" for a SDL wrapper.
Cool, though I still think we need wheel-level deps -- the dependency
is on the particular binary,
Sent from my iPhone
On Sep 27, 2015, at 11:19 AM, Ionel Cristian Mărieș
wrote:
On Sun, Sep 27, 2015 at 8:05 PM, Thomas Güttler
I don't think there can be a "definitive guide line". Unlike the core
language the packaging part of Python is a messy soup of different and
often competing ideas, s
But even if so do we WANT to now be supporting 4 Windows platforms?
win32
win32_sse2
win64
win64_sse2
and then, what about sse3, etc???
Longer term, more platforms (particularly more platforms that really only
differ by some compiler flags) shouldn’t be a very big deal, because my
dream for PyPI
>> I'm not talking about in place installs, I'm talking about e.g. building a
>> wheel and then tweaking one file and rebuilding -- traditionally build
>> systems go to some effort to keep track of intermediate artifacts and reuse
>> them across builds when possible, but if you always copy the sour
On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote:
I'm using the Python from the Miniconda installer with py35 released last
week.
Then you should not expect it to be able to find compatible binary wheels
on PyPi.
Pretty much the entire point of conda is to support Numpy and friends. It's
actu
> While I understand what you're trying to achieve (and I'm in favour,
> in general) it should be remembered that pip's core goal is installing
> packages - not being a component of a development workflow.
Yes -- clear separation of concerns here!
So what IS supposed to be used in the development
> In this situation, if pip's default for finding the python environment
> were to search the path for 'python' instead of using sys.executable,
One trick here -- PATH may not be the same everywhere. For instance,
on OS-X, the environment GUI programs get is entirely independent of
the shell. So,
> If we waved our hands and were able to magically make Python package
> management perfect, what would that look like?
well, I think the command would be:
python install package_name
I know there are good reasons to keep package installer development out of
core, but if have ensurepip-- we cou
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.
Personally, I don't use IDLE for teaching, but do use iPython. But if we
> So without a plan to provide all that stuff -- I"m not sure of the utility
> of this -- how are you gong to get PIL/Pillow to work? statically link up
> the ying-yang? Not sure the linux world will take to that.
>
We can explain how things work in details for some packages, but the main
rational
I went through this list and compiled manylinux1 wheels for each of the top
15 projects in the
list (py35).
The wheels are here, if you're interested
http://stanford.edu/~rmcgibbo/wheelhouse
Cool! Are the non-manylinux dependencies all statically linked?
-CHB
___
(e.g. by bumping up
>> the base ABI from CentOS 5 to CentOS 6).
>
> The problem with this is that python 2.7 is going to be supported and
> widely used until well past the EOL of CentOS 5, and maybe even past
> the EOL of CentOS 6
Given that we're starting now ( not a year or two ago) and it'll ta
201 - 300 of 361 matches
Mail list logo
