If you'd like to have more control over what's installed, we could re-visit
the idea of adding more categories of files within distributions based on
the model of "copy each category of files to a [configurable] target
directory". Perhaps there could even be a "necessary" flag on each category
to
To what end?
28.04.2016, 21:21, Barry Warsaw kirjoitti:
On Apr 27, 2016, at 10:00 PM, Alex Grönholm wrote:
The sdist should include all the source files, including tests and
documentation. In binary distributions, however, they are just dead
weight. Do you want the full documentation and test
On Apr 27, 2016, at 10:00 PM, Alex Grönholm wrote:
>The sdist should include all the source files, including tests and
>documentation. In binary distributions, however, they are just dead
>weight. Do you want the full documentation and test suites to be installed
>for every single dependency when
Wheel has a proposal for a "wheel pack" command that might help you.
On Thu, Apr 28, 2016, 12:46 Steve Dower wrote:
> On 27Apr2016 1445, Paul Moore wrote:
> > Personally, I agree with Donald that the "normal" process of building
> > a distribution should be:
> >
> > 1.
On 27Apr2016 1445, Paul Moore wrote:
Personally, I agree with Donald that the "normal" process of building
a distribution should be:
1. Build the sdist.
2. Build wheels *from* that sdist.
3. Check the built sdist and wheels.
4. Upload the files once you've confirmed they are OK.
The tools
Actually, another thing you can do with the wheels at this point is to take
them for a spin :-)
Have pip in another virtualenv install it by using --find-links, or even
setting your own local index.
If you have tests embedded in your wheel, now would be a good time to run
them.
Best regards,
On 28 April 2016 at 00:57, Ethan Furman wrote:
> What types of things should I be doing for (3) ?
You could check the contents of the wheels to ensure they don't
contain unexpected files :-)
But in all honesty, probably not much. I only noted it as it's the
only place you
On 04/27/2016 02:45 PM, Paul Moore wrote:
On 27 April 2016 at 18:39, Ethan Furman wrote:
# Upload the files once you've checked them
twine upload *.whl dist/* # because setup.py upload can't upload prebuilt files
What a pain. :(
Personally, I agree with Donald that the "normal" process
On 27 April 2016 at 18:39, Ethan Furman wrote:
> My current process is:
>
> python3.5 setup.py sdist --format=gztar,zip bdist_wheel upload
>
> What should I be doing instead?
My suggestion would be
# Build the sdist
python3.5 setup.py sdist --format=gztar,zip
# Build the
On 04/27/2016 12:18 PM, Daniel Holth wrote:
To answer the original question, report the bug here
https://bitbucket.org/pypa/wheel
What do you know, it's already there! ;)
https://bitbucket.org/pypa/wheel/issues/99/cannot-exclude-directory
--
~Ethan~
On Wed, Apr 27, 2016 at 2:18 PM, Daniel Holth wrote:
> To answer the original question, report the bug here
> https://bitbucket.org/pypa/wheel
>
It looksl ike there's already a similar bug opened at
To answer the original question, report the bug here
https://bitbucket.org/pypa/wheel
On Wed, Apr 27, 2016 at 3:10 PM Ethan Furman wrote:
> On 04/27/2016 12:00 PM, Alex Grönholm wrote:
>
> > The sdist should include all the source files, including tests and
> >
On 04/27/2016 12:00 PM, Alex Grönholm wrote:
The sdist should include all the source files, including tests and
documentation. In binary distributions, however, they are just dead
weight. Do you want the full documentation and test suites to be
installed for every single dependency when you
The sdist should include all the source files, including tests and
documentation. In binary distributions, however, they are just dead
weight. Do you want the full documentation and test suites to be
installed for every single dependency when you deploy your application?
I sure don't.
On 04/27/2016 11:13 AM, Alex Grönholm wrote:
Are you seriously saying that you want your bdists to include tests,
documentation etc.?
However you and I agree or disagree on what should be in a bdist, the
command I ran should have produced a bdist based on the sdists I just
created in the
Whatever the ideal situation (not using distutils at all would be a
suggestion) bdist_wheel certainly has some simple bugs that make it less
fun to use sometimes.
On Wed, Apr 27, 2016 at 2:14 PM Alex Grönholm
wrote:
> Are you seriously saying that you want your bdists
On Apr 27 2016, at 2:09 pm, Ethan Furman et...@stoneleaf.us wrote:
> On 04/27/2016 10:52 AM, Donald Stufft wrote:
>
> This isn't really a problem with what you're doing. Rather it's an
issue
with the toolchain and and open question whether or not wheels should
conceptually be able to
Are you seriously saying that you want your bdists to include tests,
documentation etc.?
Most developers would not agree with you, including yours truly.
27.04.2016, 21:10, Ethan Furman kirjoitti:
On 04/27/2016 10:52 AM, Donald Stufft wrote:
This isn't really a problem with what you're
No I mean the build directory.
On Wed, Apr 27, 2016, 14:11 Ethan Furman wrote:
> On 04/27/2016 11:05 AM, Daniel Holth wrote:
>
> > Bdist_wheel just doesn't understand MANIFEST.in . Perhaps support could
> > be adapted from bdist_egg or other bdist implementations. Wheel
On 04/27/2016 11:05 AM, Daniel Holth wrote:
Bdist_wheel just doesn't understand MANIFEST.in . Perhaps support could
be adapted from bdist_egg or other bdist implementations. Wheel doesn't
do everything the setuptools or distutils implementations put into their
dist commands. Even something as
You can try to patch around the problem (and do it in every single alternative
build system once we enable support for that) or you can just fix the problem
at the "protocol" level once and for all. The fundamental problem isn't with
MANIFEST.in, it's that some indeterminite steps need to run to
On 04/27/2016 10:52 AM, Donald Stufft wrote:
This isn't really a problem with what you're doing. Rather it's an issue
with the toolchain and and open question whether or not wheels should
conceptually be able to be produced from a checkout, or if they should
only be produced from a sdist.
I feel differently.
Bdist_wheel just doesn't understand MANIFEST.in . Perhaps support could be
adapted from bdist_egg or other bdist implementations. Wheel doesn't do
everything the setuptools or distutils implementations put into their dist
commands. Even something as simple as a forced clean of
This isn't really a problem with what you're doing. Rather it's an issue with
the toolchain and and open question whether or not wheels should conceptually
be able to be produced from a checkout, or if they should only be produced
from a sdist. Problems like this are why I advocate the Checkout -
On 04/26/2016 07:10 AM, Donald Stufft wrote:
Alternatively, he could have just produced a wheel from any checkout at
all if the MANIFEST.in excluded a file that would otherwise have been
installed.
Yes. My MANIFEST.in starts with an 'exclude enum/*' and then includes
all files it wants.
On Tue, Apr 26, 2016 at 5:11 PM, Paul Moore wrote:
> > It looks like you have published a wheel built from a dirty checkout. The
> > 1.1.3 zip sdist produces a clean wheel, as expected. You should use
> > https://pypi.python.org/pypi/check-manifest in your release process.
>
On 26 April 2016 at 15:06, Ionel Cristian Mărieș wrote:
> On Tue, Apr 26, 2016 at 4:46 PM, Ethan Furman wrote:
>>
>> I just received a bug report for enum34 for python3 code in a test file.
>> Further research revealed that that file should not be included
Alternatively, he could have just produced a wheel from any checkout at all if
the MANIFEST.in excluded a file that would otherwise have been installed. This
sort of thing is why I'm an advocate that we should only build sdists from
checkouts, and wheels from sdists (at the low level anyways,
28 matches
Mail list logo