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)
On Wed, Mar 14, 2012 at 9:17 AM, Paul Moore p.f.mo...@gmail.com 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
On Wed, Mar 14, 2012 at 3:05 PM, Zvezdan Petkovic zvez...@computer.org 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,
On 14 March 2012 19:04, Tarek Ziadé ta...@ziade.org 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
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
On Fri, Oct 18, 2013 at 6:22 PM, Nick Coghlan ncogh...@gmail.com 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
On Mon, Oct 21, 2013 at 11:52 AM, Donald Stufft don...@stufft.io 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
On Tue, Oct 22, 2013 at 1:19 PM, Nick Coghlan ncogh...@gmail.com 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
On Mon, Oct 28, 2013 at 3:50 PM, PJ Eby p...@telecommunity.com 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
On Thu, Oct 31, 2013 at 2:34 PM, Nick Coghlan ncogh...@gmail.com 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
On Thu, Oct 31, 2013 at 9:49 AM, Daniel Holth dho...@gmail.com 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 Fri, Nov 1, 2013 at 6:59 AM, Paul Moore p.f.mo...@gmail.com 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
On Fri, Nov 1, 2013 at 5:45 PM, Nick Coghlan ncogh...@gmail.com 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
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
On Mon, Dec 2, 2013 at 5:22 AM, Nick Coghlan ncogh...@gmail.com 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
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 ncogh...@gmail.com 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
On Wed, Dec 4, 2013 at 12:56 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
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
On Thu, Dec 5, 2013 at 5:52 PM, Donald Stufft don...@stufft.io 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, and allow users to re
On Thu, Dec 5, 2013 at 11:21 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
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
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Dec 6, 2013 at 4:33 AM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Dec 6, 2013 at 5:06 AM, David Cournapeau courn...@gmail.com 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
On Fri, Dec 6, 2013 at 5:16 AM, Thomas Heller thel...@ctypes.org 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
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 ()
On Sat, Dec 21, 2013 at 2:57 AM, Nick Coghlan ncogh...@gmail.com 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
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 write
On Tue, Dec 24, 2013 at 2:28 PM, Nick Coghlan ncogh...@gmail.com 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
On Mon, Jan 6, 2014 at 12:26 PM, Steve Spicklemire st...@spvi.com 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
On Mon, Jan 6, 2014 at 3:20 PM, Steve Spicklemire st...@spvi.com 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,
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau courn...@gmail.com 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
What David said, plus:
On Thu, Jan 9, 2014 at 10:43 PM, Steve Spicklemire st...@spvi.com 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
On Thu, Jan 23, 2014 at 12:25 PM, Thomas Heller thel...@ctypes.org 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
On Fri, Jan 24, 2014 at 2:18 AM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Jan 24, 2014 at 2:40 PM, Paul Moore p.f.mo...@gmail.com 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
On Sat, Jan 25, 2014 at 4:29 PM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Jan 29, 2014 at 2:04 PM, David Cournapeau courn...@gmail.comwrote:
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
On Thu, Mar 6, 2014 at 4:27 PM, MinRK benjami...@gmail.com 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 discusion
On Fri, Mar 7, 2014 at 9:50 AM, Brian Wickman wick...@gmail.com 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
On Thu, Mar 27, 2014 at 2:23 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 Mar 2014 05:42, Daniel Holth dho...@gmail.com 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
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
On Wed, Jun 11, 2014 at 9:09 AM, Daniel Holth dho...@gmail.com 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
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 chris.bar...@noaa.gov
wrote
On Fri, Jul 25, 2014 at 7:21 AM, Daniel Holth dho...@gmail.com 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
On Wed, Sep 24, 2014 at 6:55 AM, Paul Moore p.f.mo...@gmail.com 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 --
On Wed, Sep 24, 2014 at 11:49 AM, Paul Moore p.f.mo...@gmail.com 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)
On Thu, Sep 25, 2014 at 8:15 AM, David Cournapeau courn...@gmail.com
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
On Wed, Oct 1, 2014 at 9:44 AM, David Genest david.gen...@ubisoft.com
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
On Wed, Oct 1, 2014 at 5:44 PM, David Genest david.gen...@ubisoft.com
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
On Mon, Oct 27, 2014 at 8:30 AM, Marius Gedminas mar...@pov.lt 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
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 don...@stufft.io 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
On Tue, Dec 30, 2014 at 2:21 PM, Reinout van Rees rein...@vanrees.org
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
On Wed, Dec 31, 2014 at 9:10 AM, Nick Coghlan ncogh...@gmail.com 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
really don't want this handled there.
-Chris
On Wed, Dec 31, 2014 at 9:41 AM, Chris Barker chris.bar...@noaa.gov wrote:
On Wed, Dec 31, 2014 at 9:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
The problem always existed - it's the longstanding conflict between
platform independent, language
in order to then extract the dependency meta-data -- it
would be nice to not do that.
It actually succeeds with a lot of packages without any hand-editing after
the fact, to it's not so bad!
As Chris Barker notes, --single-version-externally-managed is a good way
to get setuptools-based setup.py's
option available.
yup -- so I need to tack that on when needed, and can't just do it for all
python packages...
Thanks -- that does make things a bit more clear!
-CHB
Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
On Thu, Mar 19, 2015 at 6:17 PM, Chris Barker chris.bar
On Thu, Mar 19, 2015 at 9:56 AM, Chris Barker chris.bar...@noaa.gov wrote:
On Thu, Mar 19, 2015 at 9:26 AM, Ionel Cristian Mărieș cont...@ionelmc.ro
wrote:
The --record is for making a list of installed files. You don't need it
if you don't use record.txt anywhere.
thanks -- Ill take
On Thu, Mar 19, 2015 at 9:12 AM, Ionel Cristian Mărieș cont...@ionelmc.ro
wrote:
Worth considering, if you can afford it, to have a local patch that you
apply before building. Then you have all the necessary fixes (like remove
the setup_requires) in that patch file.
yup -- that's a option
On Thu, Mar 19, 2015 at 6:57 AM, Daniel Holth dho...@gmail.com wrote:
If that's what you want then we could say the spec was to put the
requirements in setup_requires.txt, in the requirements.txt format,
which pip would eventually look for and install before running
setup.py
yes, that would
On Wed, Mar 18, 2015 at 10:37 AM, Daniel Holth dho...@gmail.com wrote:
The behavior we're aiming for would be:
installer run setup.py - installs things
python setup.py - does not install things
yup.
Which, now that I look at it, is not so different than:
python setup.py build # does not
On Thu, Mar 19, 2015 at 7:12 AM, Daniel Holth dho...@gmail.com wrote:
... except that there are plenty of reasons we wouldn't want the
requirements.txt format, mainly because pip shouldn't automatically
install concrete dependencies that contain git:// urls etc.
is that format problem, or a
On Wed, Mar 18, 2015 at 9:02 AM, Ionel Cristian Mărieș cont...@ionelmc.ro
wrote:
On Wed, Mar 18, 2015 at 5:33 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
I don't want it downloading and installing dependencies when I go to
build. That's an install- time task.
Sounds
On Wed, Mar 18, 2015 at 8:43 AM, Paul Moore p.f.mo...@gmail.com wrote:
I suppose it's too late now, but the really painful parts of all this
seem to be due to overly aggressive backward compatibility. We now
have wheels, but also eggs, we now have pip, but also easy_install,
etc.
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg drsali...@gmail.com wrote:
Is this the general perspective on static linking of python module
dependencies? That if your systems are the same, you don't need to?
That's general -- nothing specific to python here.
There _may_ be a difference in
On Mon, Apr 13, 2015 at 1:19 PM, David Cournapeau courn...@gmail.com
wrote:
This is what we use on top of setuptools egg:
- ability to add dependencies which are not python packages (I think most
of it is already handled in metadata 2.0/PEP 426, but I would have to
re-read the PEP
On Wed, Apr 22, 2015 at 5:31 PM, Donald Stufft don...@stufft.io wrote:
This seems SO SIMPLE.
...
What am I missing?
Prior to PEP 420 you needed the dynamic path stuff because sometimes your
namespace package is split across multiple locations on sys.path.
OK -- sure you'd need it then
A note from the peanut gallery:
I like the idea of namepace packages, but every time I've tried to use
them, I've been stymied -- maybe this PEP will solve that, but...
First - the issues:
- It somehow seems like a lot of work, details to get right, and
more-than-one-way-to-do-it. But maybe
On Sat, May 16, 2015 at 12:04 PM, David Mertz dme...@continuum.io wrote:
Continuum has a great desire to make 'pip' work with conda packages.
Obviously, we love for users to choose the Anaconda Python distribution but
many will not for a variety of reasons (many good reasons).
Hmm -- this
On Fri, May 15, 2015 at 11:35 PM, David Cournapeau courn...@gmail.com
wrote:
On Sat, May 16, 2015 at 4:56 AM, Chris Barker chris.bar...@noaa.gov
wrote:
But in short -- I'm pretty sure there is a way, on all systems, to have a
standard way to build extension modules, combined with a standard
On Sat, May 16, 2015 at 4:13 AM, Paul Moore p.f.mo...@gmail.com wrote:
Though it's a lot harder to provide a build environment than just the
lib to
link too .. Im going to have to think more about that...
It seems to me that the end user doesn't really have a problem here
(pip install
On Sat, May 16, 2015 at 10:12 AM, Nick Coghlan ncogh...@gmail.com wrote:
Maybe, but it's a problem to be solved, and the Linux distros more or
less
solve it for us, but OS-X and Windows have no such system built in (OS-X
does have Brew and macports)
Windows 10 has Chocalatey and
On Sat, May 16, 2015 at 11:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
could you clarify a bit -- I thought that this could, at least, put a
dir on
the search path that was specific to that python context. So it would
require cooperation among all the packages being used at once, but not
On Thu, May 14, 2015 at 4:41 PM, Robert Collins robe...@robertcollins.net
wrote:
anyway) you now have three copies of the same lib (but maybe different
versions) all linked into your executable. Maybe there is no downside to
that (I haven't had a problem yet), but it seems like a bad way to
I'm confused -- you don't want a system to be able to install ONE
version
of a lib that various python packages can all link to? That's really the
key use-case for me
Are we talking about Python libraries accessed via Python APIs, or
linking to external dependencies not written in
On Fri, May 15, 2015 at 1:44 PM, Paul Moore p.f.mo...@gmail.com wrote:
Is there any point? or is the current approach of statically linking all
third party libs the way to go?
If someone can make it work, that would be good. But (a) nobody is
actually offering to develop and maintain such
On Sun, May 17, 2015 at 5:12 PM, Robert Collins robe...@robertcollins.net
wrote:
But I'm confused as to the roles of pip vs setuptools, vs wheel, vs ???
I see pip has handling the dependency resolution, and finding and
downloading of packages part of the problem -- conda does those
Trying to keep this brief, because the odds of my finding time to do much
with this are slim..
I'm not proposing that we drop it -- just that we push pip and wheel a
bit farther to broaden the supported user-base.
I can't stop you working on something I consider a deep rabbithole,
no -- but I
On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan ncogh...@gmail.com wrote:
% pip install --upgrade pip
% pip install some_conda_package
This gets the respective role of the two tools reversed - it's like my
asking for pip install some_fedora_rpm to be made to work.
I agree here -- I
On Mon, May 18, 2015 at 11:21 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 18 May 2015 at 18:50, David Mertz dme...@continuum.io wrote:
% pip install conda
% conda install scientific_stuff
% conda install --sdist django_widget # we know to look on PyPI
But that doesn't give
A member of the conda dev team could answer this better than I, but I've
used enough to _think_ I understand the basics:
On Mon, May 18, 2015 at 3:30 AM, Paul Moore p.f.mo...@gmail.com wrote:
One way forward in terms of building wheels is to use any build
process you like to do an isolated
On Mon, May 18, 2015 at 10:50 AM, David Mertz dme...@continuum.io wrote:
This pertains more to the other thread I started, but I'm sort of becoming
convinced--especially by Paul Moore's suggestion there--that the better
approach is to grow conda (the tool) rather than shoehorn conda packages
On Fri, May 15, 2015 at 1:49 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 14 May 2015 at 19:01, Chris Barker chris.bar...@noaa.gov wrote:
Ah -- here is the issue -- but I think we HAVE pretty much got what we
need
here -- at least for Windows and OS-X. It depends what you mean by
curated
On Tue, Apr 14, 2015 at 8:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
The main two language independent solutions I've identified for this
general user level package management problem in the Fedora
Environments Stacks context
(
If there’s a plugin that understands this extension
installed, let it do something before you actually move the files into
place”. This let’s Wheels themselves still be declarative and moves the
responsibility of implementing these bits into their own PyPI projects
that can be versioned
On Tue, Apr 14, 2015 at 8:57 PM, Kevin Horn kevin.h...@gmail.com wrote:
Personally, I'm not a fan of auto-installing,
I'm with Paul on this one. It seems to me that auto-installing the
extension would destroy most of the advantages of distributing the
extensions separately.
Exactly -- I
On Wed, Apr 15, 2015 at 2:23 PM, Paul Moore p.f.mo...@gmail.com wrote:
In the PEP, there's a concept of optional vs required extensions.
See https://www.python.org/dev/peps/pep-0426/#required-extension-handling.
This is crucial - I've no problem if a particular extension is used by
a project,
NOTE: I don't work for any of the companies involved -- just a somewhat
frustrated user... And someone that has been trying for years to make
things easier for OS-X users.
I’m not sure what (3) means exactly. What is a “normal” Python, do you
modify Python in a way that breaks the ABI but which
On Tue, Apr 14, 2015 at 9:46 AM, Paul Moore p.f.mo...@gmail.com wrote:
Could an extension be -- run this arbitrary Python script ?
The main point (as I see it) of an extension is that it's
distributed independently of the packages that use it. So you get to
decide to use an extension (and
On Tue, May 19, 2015 at 4:27 AM, Oscar Benjamin oscar.j.benja...@gmail.com
wrote:
Surely the best way to manage non-Python shared libs is by
exposing them as extension modules which can be packaged up on PyPI.
Then you have dependency resolution for pip, you don't need to worry
about the
On Mon, May 18, 2015 at 8:24 PM, Vincent Povirk madewokh...@gmail.com
wrote:
But maybe all you really need to do is teach conda to understand pip
meta-data, and/or make sure that conda write pip-compatible meta data.
Forgive me, I'm trying to follow as someone who is working with PyPI
but
On Tue, May 19, 2015 at 9:15 AM, David Cournapeau courn...@gmail.com
wrote:
Honestly, I still haven't seen a solid explanation of why (at least on
Windows) static linking isn't a viable option.
well - it does get us pretty far
Because some libraries simply don't work as static
On Sat, May 16, 2015 at 4:16 PM, Donald Stufft don...@stufft.io wrote:
On Sat, May 16, 2015 at 3:03 PM, Donald Stufft don...@stufft.io wrote:
There are a few other benefits, but that’s not anything that are inherent
in the two different approaches, it’s just things that conda has that pip
is
On Sat, May 16, 2015 at 3:03 PM, Donald Stufft don...@stufft.io wrote:
There are a few other benefits, but that’s not anything that are inherent
in the two different approaches, it’s just things that conda has that pip
is planning on getting,
Huh? I'm confused -- didn't we just have a big
On Tue, May 19, 2015 at 4:12 PM, salil GK gksa...@gmail.com wrote:
I will provide more details about what I need to achieve
I need to create a package for a tool that I create. Actually the tool
that I created is a wrapper over ovftool which is provided by VMWare.
ovftool install binary is
On Wed, May 20, 2015 at 6:30 AM, Daniel Holth dho...@gmail.com wrote:
The package includes its build recipe in info/recipe
very cool -- I hadn't seen that -- I'll go take a look at some packages and
see what I can find.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response
The package includes its build recipe in info/recipe
very cool -- I hadn't seen that -- I'll go take a look at some packages
and see what I can find.
Darn -- the recipe is not there in most (all?) of the packages that came
from Anaconda -- probably due to the legacy issues David referred
On Wed, May 20, 2015 at 1:04 AM, Paul Moore p.f.mo...@gmail.com wrote:
https://github.com/menpo/conda-recipes/tree/master/libxml2
don't know anything about it.
OK, I'm still misunderstanding something, I think. As far as I can
see, all that does is copy a published binary and repack
On Tue, May 19, 2015 at 3:09 PM, Paul Moore p.f.mo...@gmail.com wrote:
So, for example the process for building the pyyaml package available
via conda is private?
well, I haven't been able to find them... I don't know if continuum keeps
them private on purpose or, just haven't happened to
1 - 100 of 348 matches
Mail list logo
