On 01/11/2017 10:26 AM, Brett Cannon wrote:
I know both Cory Benfield and Christian Heimes brought this up briefly
at the PyCon US 2016 language summit at the end of their SSL discussion,
but I don't think it went anywhere because there was some other
discussion that dominated the end of
On 01/05/2017 11:37 AM, Nick Timkovich wrote:
I never determined what was causing my problem, I couldn't reproduce it
on testpypi so I gave up (it's a small package, and if someone wants the
source, they can look at the GH link I have in the metadata).
Do you have both a .zip and a .tar
On 01/05/2017 09:58 AM, Donald Stufft wrote:
.tar.gz is the recommended format ...
.tar.gz it is! Thanks!
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 01/05/2017 08:46 AM, Donald Stufft wrote:
On Jan 5, 2017, at 11:45 AM, Ethan Furman wrote:
Do I need to choose between zip and tar sdists?
Yes.
I haven't followed Windows O/Ses for a while now -- are they able to easily
access tar files? Or do *nix machines come standard with unzip
On 12/22/2016 12:41 PM, Donald Stufft wrote:
There is a fairly new restriction that you can only have *one* sdist per
release now. That should not apply at all to Wheels and if it is, then it
is a bug. I can’t reproduce this issue though, so I’m going to guess
there was some bit of confusion
On 05/10/2016 05:39 PM, Brett Cannon wrote:
Donald, Nathaniel, and I have finished our proposed PEP for specifying a
projects' build dependencies.
Looks great! Thanks to all three of you!
+1 to build-system.
It's entirely possible to have other sections with the word 'build' in
them, so
On 05/10/2016 09:38 AM, Alex Grönholm wrote:
10.05.2016, 19:35, Ethan Furman kirjoitti:
It's too complicated and error-prone. If we want buy-in from casual
packagers then our configuration language needs to be simple to
understand and simple to get right. (The amount of leading whitespace
On 05/10/2016 08:41 AM, Alex Grönholm wrote:
10.05.2016, 18:26, Ethan Furman kirjoitti:
Please no. I'd rather do xml than yaml.
Why do you hate it so much? I strongly prefer YAML to anything else I've
seen here.
It's too complicated and error-prone. If we want buy-in from casual
On 05/10/2016 08:14 AM, Donald Stufft wrote:
On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote:
(as an aside, if there's the question of forking an existing parser
implementation for better vendorability, forking a YAML parser may be
more useful to third-party folks than forking a TOML
On 05/10/2016 01:54 AM, Paul Moore wrote:
Writing our own is simply a way to end up with additional maintenance
work, that we really don't have the resources for.
I like writing tools.
If the format is one I can get behind I'm happy to be the resource for
it. This rules out JSON and YAML,
On 05/09/2016 08:35 PM, Nathaniel Smith wrote:
On Mon, May 9, 2016 at 7:22 PM, Ethan Furman wrote:
After further consideration, and pytoml's author's comment about the spec
changing without a version increase, I think we might be better off
rolling our own.
He's a bit confused
I just found this on StackOverflow:
http://stackoverflow.com/a/648487/208880
tl;dr
-
> Recently I was working upon a project and I realised that I wanted to
> have conditionals inside my configuration file [...]
>
> I didn't want to write a mini-language, because unless I did it very
>
On 05/09/2016 05:19 PM, Ethan Furman wrote:
On 05/07/2016 09:32 AM, Brett Cannon wrote:
I also checked pytoml at https://github.com/avakar/pytoml and it looks
like it's pretty stable; no changes in the past 5 months except to
support Python 3.5 and only 3 issues. And the format is simple
On 05/09/2016 12:30 PM, Barry Warsaw wrote:
Also, I think it makes a lot of sense to go with YAML even if it isn't the
best most readable option. It's much more common than TOML so the learning
curve will be lessened.
I'd rather learn some new syntax that is readable than be stuck with a
On 05/07/2016 04:11 PM, Robert Collins wrote:
Actually, Nathaniel didn't test vendorability of the libraries, and pip
needs that. Pyyaml isn't in good shape there.
Um, what does "vendorability" mean?
--
~Ethan~
___
Distutils-SIG maillist -
On 05/07/2016 09:32 AM, Brett Cannon wrote:
+1 for TOML from me as well. I know Paul brought up the lack of
familiarity, but the format is simple and the Rust community is already
fully dependent on it so at worst Rust + us could always just ignore
future format versions if necessary.
If TOML
On 05/06/2016 07:59 PM, Nathaniel Smith wrote:
Here's that one-stop writeup/comparison of all the major configuration
languages that I mentioned:
https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f
Very nice work-up, thanks!
However, you didn't include XML -- which, while
On 05/06/2016 09:48 AM, Leonardo Rochael Almeida wrote:
On 6 May 2016 at 13:15, Chris Barker wrote:
"python literals" is perfectly well defined -- both by the language
reference, and by "can be parsed by ast.literal_eval" and it addresses
>> the limitations of JSON and is fully declarative.
On 05/04/2016 04:29 PM, Alex Grönholm wrote:
Different files for what? Something not covered by PEP 508?
Somebody will have to distill that PEP, I have only an small inkling of
what it's trying to say.
As for my specific use case: I have Python3-only files in my
distribution, so they
On 05/04/2016 03:28 PM, Paul Moore wrote:
On 4 May 2016 at 23:11, Chris Barker wrote:
That basically repeats the mistake that was made with setup.py. We
explicitly don't want an executable format for specifying build
configuration.
Executable code or not, we need to be able to specify
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&quo
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 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
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
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
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.
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 02/18/2016 12:00 PM, Daniel Holth wrote:
> On Thu, Feb 18, 2016 at 9:06 AM, Ethan Furman wrote:
>> I saw PEP-0516 go through check-ins, and had a question about the
>> pypa.json portion of the proposal -- namely, why are we using a
>> .json file?
>>
Greetings!
I saw PEP-0516 go through check-ins, and had a question about the
pypa.json portion of the proposal -- namely, why are we using a .json file?
I presume this is a file that will be created by hand, and while json is
not as ugly as xml, it's certainly not pretty.
Can we not use an
On 07/10/2015 12:00 AM, David Cournapeau wrote:
They do what almost everybody distributing large applications on Linux do : they
ship the world. Any large binary python distribution provider does the same
here: except for low level X11/glibc libraries, everything else is bundled as
part of
I have recently received a request to make installing enum34 a no-op on
Python3.4 and later so that wheels, etc, don't have to worry about the Python
version when dealing with Enum.
From an enum34 point-of-view this makes sense since Enum is in the stdlib in 3.4+, and enum34 has no purpose --
On 07/10/2015 02:47 PM, Randy Syring wrote:
Seems to me this would be handled in the upstream packages that are depending
on enum34.
IMO, it would be their responsibility to only include enum34 if their package
is being
installed on a python that needs it.
To ask enum34 to be installed and
On 01/29/2015 08:58 PM, Ben Finney wrote:
Ethan Furman writes:
However, I feel that requiring a dependency simply for the
installation of the main package (the main package doesn't actually
use this install-dependency, correct?) is heavy-handed and should be
avoided.
It is ideally
On 12/16/2014 05:49 PM, Donald Stufft wrote:
So the *primary* use case that motivated local versions is things like when
Debian
patches a copy of a project they can indicate that they’ve done so by
changing the
version to 1.0+dfsg1 or so instead of 1.0. A related use case is the one
On 12/16/2014 06:48 PM, Donald Stufft wrote:
Now if you have 1.3+debian1 installed via apt-get (or any means really), and
you’ll get the following behaviors (show with pip):
- pip install yourthing - 1.3+debian1 satisfies the constraint of anything,
so it stays installed.
- pip install
Oh, to be clear: There are no guarantees that 1.4 actually includes the
bug-fixes in +debian1, correct? It's just a
big hope?
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Distutils-SIG maillist - Distutils-SIG@python.org
I have a couple languishing laptops that still have XP on them.
I have one desktop with Win7, used primarily for unittesting my modules (no dev tools beyond Python, although I should
get VS on it at some point).
--
~Ethan~
___
Distutils-SIG maillist
[redirecting to list]
On 11/05/2014 10:30 AM, Ian Cordasco wrote:
On Nov 5, 2014 12:24 PM, Ethan Furman wrote:
I have four packages on PyPI: antipathy, dbf, pandaemonium, and scription.
`pip install --upgrade` works for three of them, but for scription it
continually grabs an older release
I have four packages on PyPI: antipathy, dbf, pandaemonium, and scription.
`pip install --upgrade` works for three of them, but for scription it
continually grabs an older release (0.53, I think).
Any ideas what might be wrong?
--
~Ethan~
___
On 10/27/2014 08:26 AM, Paul Moore wrote:
On 27 October 2014 15:07, Ethan Furman et...@stoneleaf.us wrote:
Paul Moore also declaimed:
Alternatively, you could distribute all 3 files [...]
The problem I have with this method is that the last time I tried it
setup.py attempted to pre-compile
If there is an answer, tutorial, readme, or docs that would help, a link would
be greatly appreciated.
I have finally converted my dbf library to Python3, but I want to also continue supporting at least 2.7, and I see no
reason to remove the existing library which also supports back to 2.4.
Argh. That should have been 'which is a module'.
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 10/27/2014 07:04 AM, Paul Moore wrote:
On 27 October 2014 13:47, Ethan Furman et...@stoneleaf.us wrote:
So I have multiple problems:
- how do I tell PyPI that this file is for Python2.4 - 2.6, this other
file is for 2.7, and this other other file is for 3.3+ ?
- if I have to stick
+1 to everything Nick said.
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 09/28/2014 12:31 PM, Donald Stufft wrote:
I'd like to discuss the idea of moving PyPI to having immutable files.
Perhaps I'm missing something, but I already get errors if I try to reupload a
package with the same version number.
--
~Ethan~
___
On 09/28/2014 02:29 PM, Richard Jones wrote:
The intent was always that files were immutable. The deleting loophole is just
something that I never got around to fixing.
+1 to fix that bug :)
Agreed! :)
--
~Ethan~
___
Distutils-SIG maillist -
On 09/28/2014 02:54 PM, John Yeuk Hon Wong wrote:
On 9/28/14 5:23 PM, Donald Stufft wrote:
You can delete them and then reupload the same file with different contents.
Sorry, but I am confused: what does different content mean in contrast to same
file?
Same file name, but different stuff
On 09/28/2014 02:36 PM, M.-A. Lemburg wrote:
-1.
It does happen that files need to be reuploaded because of a bug
in the release process and how people manage their code is really
*their* business, not that of PyPI.
There exists problems in the ecosphere now with pylockfile because two
On 01/14/2014 01:26 PM, Dan Stromberg wrote:
On Sat, Jan 11, 2014 at 2:04 PM, Dan Stromberg drsali...@gmail.com wrote:
Hi folks.
I have a setup.py problem that's driving me nuts.
Anyone? I've received 0 responses.
I have no answer, but forwarding to Distutils (hopefully it's an
',
'test/test_enum.py',
]
},
license='BSD License',
description='Python 3.4 Enum backported to 3.3, 3.2, 3.1, 2.7, 2.6, 2.5,
and 2.4',
long_description=long_desc,
provides=['enum'],
author='Ethan Furman',
author_email
On 07/01/2013 12:11 PM, Paul Moore wrote:
On 1 July 2013 19:19, Ethan Furman et...@stoneleaf.us
mailto:et...@stoneleaf.us wrote:
ethan@media:~/source/enum$ python setup.py sdist --formats tar upload
running sdist
running check
reading manifest template 'MANIFEST.in'
writing
On 06/29/2013 02:07 AM, Nick Coghlan wrote:
On 29 June 2013 10:09, Ethan Furman et...@stoneleaf.us wrote:
Am I making this too complicated? Can I just do my renaming in the setup.py
script before calling the setup function?
You can't easily create a wheel that way.
What would actually
On 06/28/2013 04:45 PM, Ethan Furman wrote:
On 06/27/2013 11:55 AM, Oscar Benjamin wrote:
On 27 June 2013 18:31, Ethan Furman et...@stoneleaf.us wrote:
It occur to me now that the reason I don't see this kind of error on
my project is because in the setup.py I am just excluding the
version
On 06/27/2013 11:55 AM, Oscar Benjamin wrote:
On 27 June 2013 18:31, Ethan Furman et...@stoneleaf.us wrote:
It occur to me now that the reason I don't see this kind of error on
my project is because in the setup.py I am just excluding the
version-specific files based on what Python version
On 06/27/2013 10:19 AM, Erik Bray wrote:
On Wed, Jun 26, 2013 at 4:21 PM, Erik Bray erik.m.b...@gmail.com wrote:
On Sun, Jun 16, 2013 at 3:13 AM, Ethan Furman et...@stoneleaf.us wrote:
Here's my file layout:
root /
|- setup.py
|
|- enum /
|- __init__.py
On 06/26/2013 01:21 PM, Erik Bray wrote:
On Sun, Jun 16, 2013 at 3:13 AM, Ethan Furman et...@stoneleaf.us wrote:
Here's my file layout:
root /
|- setup.py
|
|- enum /
|- __init__.py
|
|- py2_enum.py
On 06/26/2013 01:23 PM, Donald Stufft wrote:
If I recall this is because it's trying to compile byte code.
Is there an option to tell distutils not to compile byte code?
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
On 06/26/2013 01:35 PM, Carl Meyer wrote:
On 06/26/2013 02:23 PM, Donald Stufft wrote:
If I recall this is because it's trying to compile byte code.
That's correct. And you'll note that despite the scary-looking syntax
errors from byte-compilation, the install actually succeeded.
I did
On 06/15/2013 10:13 AM, Tres Seaver wrote:
On 06/15/2013 02:29 AM, Ethan Furman wrote:
Any ideas? Is this the right place to post?
This is the right place. Your 'package_data' declaration is getting munged::
[snip]
Looking at the 'build_py' step, this line is problematic
Here's my file layout:
root /
|- setup.py
|
|- enum /
|- __init__.py
|
|- py2_enum.py
|
|- py3_enum.py
|
|- test /
|- test_enum.py
',
long_description=long_desc,
provides=['enum'],
author='Ethan Furman',
author_email='et...@stoneleaf.us',
classifiers=[
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD
61 matches
Mail list logo
