On Jan 19, 2015, at 8:50 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Tres Seaver tsea...@palladion.com writes:
setuptools itself is extensible by means of entry points. Both entry
points in your example (as cited by Marius) demonstrate that: one adds
support for a new keyword
Have you had a go with https://bitbucket.org/dholth/setup-requires ? I
wrote it because it has always been problematic putting setup_requires
in setup.py to try to get something that setup.py must import into the
global namespace before it can run. I'd love to see some build helpers
that take
Tres Seaver tsea...@palladion.com writes:
setuptools itself is extensible by means of entry points. Both entry
points in your example (as cited by Marius) demonstrate that: one adds
support for a new keyword argument to 'setup()'[1], and the other
defines a new writer for 'egg-info'[2]. By
Ben Finney ben+pyt...@benfinney.id.au writes:
That has worked for me. But it appears to cause problems for some
others, related to this module which should not be installed.
This discussion was prompted, for me, by this bug report
Nick Coghlan ncogh...@gmail.com writes:
I actually misunderstood your question. If you're just after the
ability to say I want to include this file in the sdist, but not in
the built wheel file or installed distribution (as I now believe you
are)
Correct, that's the goal here.
then you're
On Tue, Jan 20, 2015 at 12:50:14PM +1100, Ben Finney wrote:
Tres Seaver tsea...@palladion.com writes:
setuptools itself is extensible by means of entry points. Both entry
points in your example (as cited by Marius) demonstrate that: one adds
support for a new keyword argument to
If you're just after the ability to say I want to include this file in
the sdist, but not in the built wheel file or installed distribution (as I
now believe you are)
I think that you can add the file to the MANIFEST.in file to achieve the
desired behavior.
-Robert
On Sun, Jan 18, 2015 at
On 19 January 2015 at 17:45, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com writes:
If you'd like to volunteer for the task of reverse engineering and
properly documenting how sdists work (with regression tests!), that
would be quite awesome. Not necessarily
On 19 January 2015 at 18:23, Ben Finney ben+pyt...@benfinney.id.au wrote:
Unfortunately this kind of problem (trouble post-install from a PyPI
package) is difficult to test. How can I test the behaviour of ‘pip’ in
this regard, without thrashing many releases of a package upload to
PyPI?
A
On Mon, Jan 19, 2015 at 07:37:35PM +1100, Ben Finney wrote:
Ben Finney ben+pyt...@benfinney.id.au writes:
That has worked for me. But it appears to cause problems for some
others, related to this module which should not be installed.
This discussion was prompted, for me, by this bug report
On 01/19/2015 01:23 AM, Ben Finney wrote:
[snip]
My understanding, based on an answer received elsewhere [0], is that
omitting the file from ‘setup.py’ but adding it to ‘MANIFEST.in’ causes
it to be included in the sdist but omitted from install targets.
[0]
On 01/19/2015 12:39 AM, Nick Coghlan wrote:
On 19 January 2015 at 11:59, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com writes:
I actually misunderstood your question. If you're just after the
ability to say I want to include this file in the sdist, but not in
Nick Coghlan ncogh...@gmail.com writes:
For projects under the PyPA banner, including packaging.python.org,
license in = license out is fine. That text is CC-BY-SA, so including
Apache Licensed text shouldn't pose any problems.
Okay. So with which repository from
Marius Gedminas mar...@gedmin.as writes:
(It would be a bit easier if Alioth didn't require creating a guest
account and logging in just to read a public bug report.)
You're right, I wasn't aware of that. I have filed a feature request
14 matches
Mail list logo
