On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
(your quote trimming's a bit over-enthusiastic, you lost the attribution here)
python -m something rather than just something isn't broken, it's
just an inconvenience.
Tell that to a newbie. This is EXACTLY
The wheel installer does call setuptools to generate console script
wrappers.
On Apr 18, 2015 1:36 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
(your quote trimming's a bit over-enthusiastic, you lost the
On 18 April 2015 at 13:36, Paul Moore p.f.mo...@gmail.com wrote:
On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
(your quote trimming's a bit over-enthusiastic, you lost the attribution here)
python -m something rather than just something isn't broken,
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
On 18 April 2015 at 20:02, Nick Coghlan ncogh...@gmail.com wrote:
It's a huge quality of implementation issue, certainly - any
installer that doesn't include script generation built in is going to
be as annoying as hell to a user. But they do exist (wheel install,
for instance) and the
On 16 April 2015 at 00:48, Steve Dower steve.do...@microsoft.com wrote:
On the Start Menu suggestion, I think that's a horrible idea. Pip is not the
system package manager and it shouldn't be changing the system. Unversioned
script launchers are in the same category, but aren't quite as
On 16 April 2015 at 08:30, Tim Golden m...@timgolden.me.uk wrote:
Sorry - I agree it's an awful idea. Older wininst installers such as
the pywin32 (and I think the PyQT one) one do this, I wanted to use it
as an example of abuse of postinstall scripts that should *not* be
perpetuated in any
On 16/04/2015 08:08, Paul Moore wrote:
On 16 April 2015 at 00:48, Steve Dower steve.do...@microsoft.com wrote:
On the Start Menu suggestion, I think that's a horrible idea. Pip is not the
system package manager and it shouldn't be changing the system. Unversioned
script launchers are in the
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,
On 16 Apr 2015 03:08, Paul Moore p.f.mo...@gmail.com wrote:
Just to expand on another point in my mail - I'd like *anyone* to
provide an example of a genuine use case for something they think
should be a required installer extension. I'm not sure such a thing
actually exists...
The
On 16 Apr 2015 14:34, Paul Moore p.f.mo...@gmail.com wrote:
By the way. I just did a check through PEPs 426 and 459. Neither one
currently defines a postinstall script metadata item or extension,
which is interesting given that this discussion started from the
question of how postinstall
On 16 April 2015 at 17:58, Chris Barker chris.bar...@noaa.gov wrote:
We have the same problem with optional dependencies.
For instance, for iPython to work, you don't need much. but if you want the
ipython notebook to work, you need tornado, zeromq, who knows what else. But
people want it to
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
Barkermailto:chris.bar...@noaa.gov
Cc: distutils-sigmailto:distutils-sig@python.org
Subject: Re: [Distutils] Beyond wheels 1.0: helping downstream, FHS and more
On 15 April 2015 at 21:40, Chris Barker chris.bar...@noaa.gov wrote:
Which brings us back to the review of extensions thing -- I think it's
less
On 15 April 2015 at 21:40, Chris Barker chris.bar...@noaa.gov wrote:
Which brings us back to the review of extensions thing -- I think it's
less about the end user checking it out and making a decision about it, but
about the package builder doing that. I have a package I want to be easy to
On 14 April 2015 at 06:37, David Cournapeau courn...@gmail.com wrote:
pywin32 is one of the most used package in the python ecosystem, and its
post install script is not trivial.
And yet pywin32's postinstall script is completely virtualenv-hostile.
It registers start menu entries (not
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
(
On 14 April 2015 at 17:10, Chris Barker chris.bar...@noaa.gov wrote:
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
On 13 April 2015 at 12:56, Chris Barker chris.bar...@noaa.gov wrote:
Which brings me back to the question: should the python tools (i.e. wheel)
be extended to support more use-cases, specifically non-python dependencies?
Or do we just figure that that's a problem better solved by projects with
On 13 April 2015 at 22:29, Donald Stufft don...@stufft.io wrote:
So a possible way for this to work is in a PEP 426 world, simply define
a twisted.plugins extension that says, in a declarative way, “hey when
you install this Wheel, if there’s a plugin that understands this extension
installed,
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 4:19 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 14 April 2015 at 22:02, Chris Barker chris.bar...@noaa.gov wrote:
Personally, I'm not a fan of auto-installing, so I'd hope for
something more like pip would fail to install if a required extension
were missing. The
On 14 April 2015 at 22:02, Chris Barker chris.bar...@noaa.gov wrote:
- pip auto-installs it (if not already there) when the user goes to install
the wheel.
Personally, I'm not a fan of auto-installing, so I'd hope for
something more like pip would fail to install if a required extension
were
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 Mon, Apr 13, 2015 at 12:56 PM, Chris Barker chris.bar...@noaa.gov
wrote:
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
On Mon, Apr 13, 2015 at 12:56 PM, Chris Barker chris.bar...@noaa.gov wrote:
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
On Mon, Apr 13, 2015 at 3:46 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Apr 13, 2015 at 12:56 PM, Chris Barker chris.bar...@noaa.gov
wrote:
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
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
I would advise against using or even reading about our egg extensions, as
the implementation is full of legacy (we've been doing this many years :)
): http://enstaller.readthedocs.org/en/master/reference/egg_format.html
This is what we use on top of setuptools egg:
- ability to add dependencies
On Mon, Apr 13, 2015 at 5:25 PM, Chris Barker chris.bar...@noaa.gov wrote:
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
Seems like you could extend wheel to do that easily.
On Apr 13, 2015 4:19 PM, David Cournapeau courn...@gmail.com wrote:
I would advise against using or even reading about our egg extensions, as
the implementation is full of legacy (we've been doing this many years :)
):
On Apr 13, 2015, at 10:17 PM, Robert Collins robe...@robertcollins.net
wrote:
On 14 April 2015 at 09:35, David Cournapeau courn...@gmail.com wrote:
...
One of the earlier things mentioned here - {pre,post}{install,remove}
scripts - raises a red flag for me.
In Debian at least, the
On 14 April 2015 at 09:35, David Cournapeau courn...@gmail.com wrote:
...
One of the earlier things mentioned here - {pre,post}{install,remove}
scripts - raises a red flag for me.
In Debian at least, the underlying system has the ability to run such
turing complete scripts, and they are a rich
On Mon, Apr 13, 2015 at 10:17 PM, Robert Collins robe...@robertcollins.net
wrote:
On 14 April 2015 at 09:35, David Cournapeau courn...@gmail.com wrote:
...
One of the earlier things mentioned here - {pre,post}{install,remove}
scripts - raises a red flag for me.
That's indeed a good a
On Mon, Apr 13, 2015 at 10:44 AM, Donald Stufft don...@stufft.io wrote:
On Apr 13, 2015, at 10:39 AM, David Cournapeau courn...@gmail.com wrote:
Hi there,
During pycon, Nick mentioned there was interest in updating the wheel
format to support downstream distributions. Nick mentioned Linux
Hi there,
During pycon, Nick mentioned there was interest in updating the wheel
format to support downstream distributions. Nick mentioned Linux
distributions, but I would like to express interest for other kind of
downstream distributors like Anaconda from Continuum or Canopy from
Enthought
On Apr 13, 2015, at 10:39 AM, David Cournapeau courn...@gmail.com wrote:
Hi there,
During pycon, Nick mentioned there was interest in updating the wheel format
to support downstream distributions. Nick mentioned Linux distributions, but
I would like to express interest for other kind
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
#1 is pretty straightforward. An entry-point format Python
pre/post/etc. script may do.
I have some ideas for the FHS, though I fear it's full of bikesheds:
1. Allow all GNU directory variables as .data/* subdirectories
(https://www.gnu.org/prep/standards/html_node/Directory-Variables.html).
The
On 13 April 2015 at 16:02, Daniel Holth dho...@gmail.com wrote:
#1 is pretty straightforward. An entry-point format Python
pre/post/etc. script may do.
There's metadata 2.0 information for this. It would be sensible to
follow that definition where it applies, but otherwise yes, this
shouldn't
On Mon, Apr 13, 2015 at 10:54 AM, David Cournapeau courn...@gmail.com wrote:
On Mon, Apr 13, 2015 at 10:44 AM, Donald Stufft don...@stufft.io wrote:
On Apr 13, 2015, at 10:39 AM, David Cournapeau courn...@gmail.com wrote:
Hi there,
During pycon, Nick mentioned there was interest in
41 matches
Mail list logo
