Re: [Distutils] Announcement: TLSv1.2 will become mandatory in the future
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 their talk (I've now tweeted at them about this discussion). I know Steve has also said he would love to see a agnostic TLS library so that Windows' built-in libraries for this stuff could be directly used. With the predicament this is going to put us in I think it makes it very prudent to create a tls module for the stdlib. A thread about a new tls module has been started on the security-sig [1]. -- ~Ethan~ [1] security-...@python.org https://mail.python.org/pipermail/security-sig/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Can't upload sdist: "File already exists"
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 source distribution? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Can't upload sdist: "File already exists"
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
Re: [Distutils] Can't upload sdist: "File already exists"
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 now? Or is it more along the lines of -- you seem to be a developer, so you should be able to install the one you need? ;) -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Can't upload sdist: "File already exists"
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 about exact errors here. If someone actually cannot upload 1 sdist + N wheels, please leave the state as is and tell me. I am also seeing this problem. My standard files for upload have been a py2 wheel, a py3 wheel, a zip sdist, and a tar sdist, and now the tar sdist is being denied as a duplicate. Do I need to choose between zip and tar sdists? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP for specifying build dependencies
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 it's better to be more explicit now. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 a single line changes your data type? Really?? 0644 and 0x644 both map to 420? and 644 maps to 644?) > Do you actually expect to use these in your project's configuration? I might. A couple in-house projects have scripts that only root should run. No? Don't assume for me, and don't assume for the hundreds (thousands? tens of thousands?) of others who will be using this. Then why is this a problem for you in this case? See above. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 packagers then our configuration language needs to be simple to understand and simple to get right. (The amount of leading whitespace on a single line changes your data type? Really?? 0644 and 0x644 both map to 420? and 644 maps to 644?) https://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html https://ciaranm.wordpress.com/2009/03/01/yaml-sucks-gems-sucks-syck-sucks/ While YAML is more easily readable than XML, with XML you already know you're in hell so you tread more carefully. ;) If we want to take the good ideas of YAML and make our own thing I'm okay with that -- but not YAML itself. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 parser :-)) I’m seeing what I can come up with (https://github.com/dstufft/yaml) though I don’t know that I feel like actually maintaining whatever it is I end up figuring out there. Please no. I'd rather do xml than yaml. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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, but leaves TOML in the running (as in: I'm happy to take over pytoml if its current author is agreeable). I'm also happy to create one: The Sane/Simple/Super Config Language (or .scl for short). It would be very similar to TOML, possibly a superset. Tools written so far: - dbf [https://pypi.python.org/pypi/dbf] project I learned Python with (so some rough edges, but very serviceable) - scription [https://pypi.python.org/pypi/scription] opinionated command-line parser - antipathy [https://pypi.python.org/pypi/antipathy] file system path library - aenum [https://pypi.python.org/pypi/aneum] totally awesome Enum library ;) (scaled-down version is the stdlib Enum) - xaml [https://pypi.python.org/pypi/xaml] xml processor similar to Ruby's haml PEPs (co)authored so for have also been tool/library oriented: - PEP 409 [https://www.python.org/dev/peps/pep-0409] raise from None (dbf inspired) - PEP 435 [https://www.python.org/dev/peps/pep-0435] Enum - PEP 461 [https://www.python.org/dev/peps/pep-0461] %-interpolation for bytes & bytearrays In other words: this is a serious offer. ;) -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 -- they didn't change 0.4.0; they made changes in their dev branch working towards 1.0.0 (some cleanups related to the date/time stuff I think?"). But of course when you go to github it shows you the current dev version, and the dev version has a prominent link at the top to the 0.4.0 tag, so if you're skimming it's easy to misread it as saying that what you're looking at is 0.4.0. Ah, okay. Thanks for clarifying! -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 > carefully I couldn't allow the flexibility that would be useful. > > Instead I decided that I'd have two forms: If the file started with > "#!" and was executable I'd parse the result of running it; otherwise > I'd read it as-is That approach seems like a win-win: the plain-vanilla static file can be promoted as best-practice, yet we have a fall-back for the complicated and edge cases. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 enough that if someone had to fork the code like Nathaniel suggested or we did it from scratch it wouldn't be a huge burden. 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. I like the general simplicity, and would stick with that, but I'd be a lot more comfortable if we had our spec that was more consistent. If there is interest I'll write the PEP and the tool. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 pain in my eyes and in my brain. ;) -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 is the chosen format we could ask how long until a 1.0 release to know if we waited a month or so to implement we could make sure we're compliant with that version. 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 enough that if someone had to fork the code like Nathaniel suggested or we did it from scratch it wouldn't be a huge burden. I would prefer TOML over anything else mentioned so far, and taking over pytoml would probably be beneficial, given the author's comments. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] comparison of configuration languages
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 absolutely horrid, can be quite readable with the appropriate preprocessor, such as xaml [1] : --- 8< whatever.xaml --- !!! xml1.0 ~base ~schema // optional ~version: 1 ~bootstrap ~requirements // Temporarily commented out 2016-01-10 // magic-build-helper ~setuptools ~version: >= 27 // for the new frobnicate feature ~numpy ~version: >= 1.10 //Pinned until we get a fix for // @https://github.com/cyberdyne/the-versionator/issues/123 ~the-versionator ~version: 0.13 // The owner of pypi name "flit" decides what goes under the // extension: flit: // key ~extensions ~flit ~whatever: true --- 8< - which ends up as: --- 8< whatever.xml 1 = 27 = 1.10 0.13 true --- 8< - -- ~Ethan~ [1] https://pypi.python.org/pypi/xaml ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] moving things forward
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. There is actually prior art for that kind of use. Odoo uses such a language for its addons system, including package dependencies. See example file here: https://github.com/OCA/maintainer-tools/blob/master/template/module/__openerp__.py Notice the `depends` key, that lists other addons, and the `external_dependencies` key that can list both python distribution dependencies as well as external program dependencies. This is one of the very few things Odoo got right. Let's not look to them for other examples of good coding practices. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] moving things forward
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 should only be installed on Python3 systems. Python2 systems generate useless errors. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] moving things forward
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 different files depending on the python version. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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 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. What types of things should I be doing for (3) ? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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 deploy your application? I sure don't. That's makes a certain amount of sense. It also raises some questions: - are wheels a binary-only distribution? - if yes, we still have to use distutils to make source distributions? - if no, what are the commands to make source vs binary distributions? - is this just a matter of a properly configured setup.py? - if yes, what is that configuration? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn'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 same command. Most developers would not agree with you, including yours truly. Well, we disagree. To me, the salient difference between an sdist and a bdist is whether binary artifacts are, um, already built. I certianly enjoy having docs (so I know how to use the binaries I just installed) and tests (so I can assure myself the binaries work as advertised). If a project is big enough I can see making separate packages for docs and/or tests, but mine are small. And whichever way we decide to do the packaging, the tools should work for us, not us for the tools. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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 simple as a forced clean of the dist directory on init may fix the problem? Um, does that mean it would destroy my files-in-progress? 'Cause that would really [insert colloquial phrase meaning extreme irritation here]. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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. Problems like this are why I advocate the Checkout -> sdist -> wheel being the only path, but others feel differently. As a simple user, my feelings are that the command I used should have generated three equivalent distributions, but did not. That feels like a bug. :( Let me rephrase my question: what command do I use to build the wheel from the sdist I just made? For bonus points: why can't setup do that for me? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] wheel including files it shouldn't
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. 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, even if the UI allows people to appear to create a wheel straight from a checkout). My current process is: python3.5 setup.py sdist --format=gztar,zip bdist_wheel upload What should I be doing instead? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 516 and pypa.json
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? >> >> 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. I'm still pulling for RFC 822 format :) You know what? xml is okay.* ;) -- ~Ethan~ * Not really! Just kidding! ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP 516 and pypa.json
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 .ini file, or a white-space significant format? The latter should be familiar, if not comfortable, to any Python programmer. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform
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 the distribution. Huh, sounds like Windows. ducks and runs -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Making install a no-op
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 -- but how? Is it a simple matter of checking for the Python version and raising SystemExit if enum34 is not needed? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making install a no-op
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 then expect enum34 to not install itself seems backwards. But that's just my $0.02. You make a good point. I have changed the classifier Python3 to Python3.1, 3.2, and 3.3 -- hopefully that will things a little easier. The request came from someone who would like to have one wheel file for all Python2-3 versions; I know that in setup.py it's easy enough to check the version and add (or not) enum34 to the required (or dependent?) module list. Does this type of thing work with wheels? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Python module for use in ‘setup.py’ but not to install
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 a build-time dependency and not an install-time dependency, but I'm having a difficult time figuring out how to distinguish those so Setuptools will pay attention. Ah, so it's needed with the sdist command and not the install command? Yeah, you definitely have my sympathies with that one. Too bad there's no easy way to specify behavior based on the command used... (hopefully someone will now tell how I am wrong about that ;) . -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Local version identifiers from PEP 440 in practice
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 you’re talking about. However the primary use case is what influenced the fact that ==1.1 matches ==1.0+foobar. Important to note, is that ==1.0+foobar will only install that patched version, not any 1.0 version. You can also approximate the kind of pinning you want with the === (which is really the arbitrary equality indicator, which is generally used for people who want to install a version like “dog” which we can’t parse). It’s possible that we could add some sort of a “None” indicator for local versions that says “1.0 and exactly 1.0” though I’m not sure how off the top of my head (Maybe ==1.0+). Let me see if I understand correctly: I release my dbf package as 1.3. Somebody at Debian fixes a bug, and rather than wait for me to release the next version just slap a local tag on it -- so now there is: - 1.3 (mine) - 1.3+debian1 At this point, a non-debian user asking for 1.3 will get mine, whereas a debian user would get the 1.3+debian1 version. Correct? Plus, a debian user asking for 1.4 would also get 1.3+debian1? Now, I fix that bug plus a few more, and make a 1.4 release. A non-debian user would get my 1.4 release. Which version will a debian user get? - 1.3+debian1 ? - 1.4 ? If my 1.4 does not sort higher than a 1.3+blahblah anything, that's not good. -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Local version identifiers from PEP 440 in practice
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 yourthing==1.3 - 1.3+debian1 satisfies the constraint of ==1.3, so it stays installed. - pip install yourthing=1.3 - 1.3+debian1 satisfies the constraint of = 1.3, so it stays installed. - pip install yourthing=1.4 - 1.3+debian1 does not satisfy the constraint of =1.4, so pip will upgrade it to 1.4. - pip install —upgrade youthing - You’ve requested an upgrade, so pip will see 1.4 exists and will install it. - pip install —upgrade yourthing==1.3 - You’ve requested an upgrade, but there’s nothing newer than 1.3+debian1 that matches the constraint so it stays installed - pip install -upgrade youthing=1.3 - You’ve requested an upgrade, pip will see 1.4 exists and satisfies the constraint and will install it. - pip install —upgrade yourthing1.4 - you’ve requested an upgrade and 1.3+debian1 is not = 1.4, so pip will see 1.4 exists and install it. Does that make sense? Yes. Thank you for that _very_ thorough explanation. :) To continue with Maurits' use-case, in order to get /exactly/ 1.3, '===' is the operator to use? Or are we still discussing that? Personally, I think pip install yourthing is 1.3 ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Local version identifiers from PEP 440 in practice
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 https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?
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 - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pip not grabbing latest PyPI version
[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 (0.53, I think). Any ideas what might be wrong? Is the newest version a pre-release? No, but that was the clue I need, thanks! 0.53.0 is a higher version than 0.7.0. Doh. Changing that to 0.70.1 now... Thanks for the help! -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] pip not grabbing latest PyPI version
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~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a package with is a module
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 all the files, resulting in syntax errors, which makes for a lousy user experience. Yeah, it's harmless but ugly. I've seen that issue myself. For the record, I thought setting PYTHONDONTWRITEBYTECODE from inside the setup.py script: os.environ['PYTHONDONTWRITEBYTECODE'] = True might do the trick, but - it isn't available on 2.5 - it doesn't work on 2.6 (didn't test on 2.7 nor 3.x) Oh well. Guess I'll include a note that says, Ignore any syntax errors during 'setup.py install', they're harmless. :( -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] a package with is a module
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. I've never been very happy with the egg format (cool name, but having the source zipped up is irritating when one wants to look at it) and so I have left this library as a couple modules: dbf.py, and dbf_test.py. 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 it all in one archive, how do I tell setup.py which to install? - is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py? How do I know where the .txt files are at to rename them? I have skimmed http://python-packaging-user-guide.readthedocs.org/en/latest/, but didn't find what I was looking for there. Thanks for any help. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a package with is a module
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
Re: [Distutils] a package with is a module
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 it all in one archive, how do I tell setup.py which to install? - is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py? How do I know where the .txt files are at to rename them? For a source distribution, you could play clever games in setup.py to put the right file in place, with the right name. But that's messy and it means that if you distribute wheels (not that there's much point in doing so) you need separate wheels for 2.6-, 2.7 and 3.3+. But how? When setup.py runs, is it guaranteed to do so in a particular location relative to the installable files? And I wouldn't mind making separate wheels, if I ever get that far. Alternatively, you could distribute all 3 files, as dbf \ - __init__.py - dbf_26.py - dbf_27.py - dbf_3.py Then in __init__.py do if sys.version_info[0] == 3: from .dbf_3 import * elif sys.version_info[:2] == (2, 7): from .dbf_27 import * else from .dbf_26 import * The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Process for taking over abandoned packages
+1 to everything Nick said. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Immutable Files on PyPI
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~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Immutable Files on PyPI
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 - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Immutable Files on PyPI
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 in that file. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Immutable Files on PyPI
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 different versions of the same version were released, and one works and one doesn't. If you screw up your build, bump the version and rerelease it. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.py issue - some files are included as intended, but one is not
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 appropriate topic ;) I have a treap.py file that tries to import * from pyx_treap.so, and failing that, it'll import * from py_treap.py (sans extensions of course). Naturally, all 3 of these should be included - although in the case of pyx_treap.so, it probably should be a .c that's included. It is also intended to include nest.py, which has a simple form. Well, treap.py, nest.py and pyx_treap.c are included fine, but I can't seem to get py_treap.py to be included for some reason. I get no errors during python setup.py sdist upload, but upon python $(which pip) install treap, I get: $ sudo /usr/bin/python $(which pip) install treap Downloading/unpacking treap Running setup.py egg_info for package treap file py_treap.py (for module py_treap) not found Installing collected packages: treap Running setup.py install for treap file py_treap.py (for module py_treap) not found file py_treap.py (for module py_treap) not found file py_treap.py (for module py_treap) not found file py_treap.py (for module py_treap) not found Successfully installed treap Cleaning up... And it's not successfully installed - py_treap.py is missing. The pyx code does its job, so the problem is masked, other than the messages above, and the absence of py_treap.py from /usr/local/lib/python2.7/dist-packages I can clearly see py_treap.py in ./dist/treap-1.35.tar.gz - it's at least getting packaged up that much. It's not listed in /usr/local/lib/python2.7/dist-packages/treap-1.31.egg-info/SOURCES.txt , but I can see it in /usr/local/lib/python2.7/dist-packages/treap-1.31.egg-info/top_level.txt . My setup.py is at: http://stromberg.dnsalias.org/svn/treap/trunk/setup.py I've tried that setup.py and several variations on that theme, but none seem to include py_treap.py . Please make some suggestions? How can I get py_treap.py included in the pip install? Thanks! ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PyPI upload: zip okay, tar fails with invalid distribution file
I migrated my split py2/py3 code base into one as I couldn't get setup to do what I wanted, and now I am having this
problem.
Here's my setup.py:
import sys, os
from distutils.core import setup
long_desc = open('enum/doc/enum.rst').read()
setup( name='enum34',
version='0.9.1',
url='https://pypi.python.org/pypi/enum34',
packages=['enum'],
package_data={
'enum' : [
'LICENSE',
'README',
'doc/enum.rst',
'doc/enum.pdf',
'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='et...@stoneleaf.us',
classifiers=[
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Programming Language :: Python',
'Topic :: Software Development' ],
)
and an example run:
ethan@media:~/source/enum$ python setup.py sdist --formats tar upload
running sdist
running check
reading manifest template 'MANIFEST.in'
writing manifest file 'MANIFEST'
creating enum34-0.9.1
creating enum34-0.9.1/enum
creating enum34-0.9.1/enum/doc
creating enum34-0.9.1/enum/test
making hard links in enum34-0.9.1...
hard linking LICENSE - enum34-0.9.1
hard linking README - enum34-0.9.1
hard linking setup.py - enum34-0.9.1
hard linking enum/__init__.py - enum34-0.9.1/enum
hard linking enum/doc/enum.pdf - enum34-0.9.1/enum/doc
hard linking enum/doc/enum.rst - enum34-0.9.1/enum/doc
hard linking enum/test/test_enum.py - enum34-0.9.1/enum/test
Creating tar archive
removing 'enum34-0.9.1' (and everything under it)
running upload
Submitting dist/enum34-0.9.1.tar to http://pypi.python.org/pypi
Upload failed (400): invalid distribution file
Any ideas?
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PyPI upload: zip okay, tar fails with invalid distribution file
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 manifest file 'MANIFEST' creating enum34-0.9.1 creating enum34-0.9.1/enum creating enum34-0.9.1/enum/doc creating enum34-0.9.1/enum/test making hard links in enum34-0.9.1... hard linking LICENSE - enum34-0.9.1 hard linking README - enum34-0.9.1 hard linking setup.py - enum34-0.9.1 hard linking enum/__init__.py - enum34-0.9.1/enum hard linking enum/doc/enum.pdf - enum34-0.9.1/enum/doc hard linking enum/doc/enum.rst - enum34-0.9.1/enum/doc hard linking enum/test/test_enum.py - enum34-0.9.1/enum/test Creating tar archive removing 'enum34-0.9.1' (and everything under it) running upload Submitting dist/enum34-0.9.1.tar to http://pypi.python.org/pypi Upload failed (400): invalid distribution file ==__==__ Any ideas? You probably want format gztar rather than tar. I don't think I've ever seen an uncompressed tar on PyPI - they probably aren't allowed... I could've sworn I've used tar before, but at any rate going with gztar did the trick. Thanks! -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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 be better is if you could avoid the need for any Python 3 specific syntax in the first place. Are you sure you can't tweak the code to use types.new_class or an inner function call to avoid the syntax problems? For example, Python 2 can do keyword only arguments like this: def _unpack_args(module=None, type=None): return module, type class CallableWithKeywordOnlyArgs def __call__(cls, value, names=None, **kwargs): module, type = _unpack_kwargs(**kwargs) The introspection support and error messages aren't as good as those for true Python 3 keyword-only arguments, but they're not *that* bad. There's a reason shared syntax compatible 2/3 source has become the most popular approach for straddling the 2/3 boundary - the alternatives are all lousy by comparison. Conditional distribution of version specific source files is far more painful than jumping through a few syntactic hoops to stay within the common 2/3 subset of the language. I was hoping to provide good examples of Python 3 code (as opposed to good examples of 2/3 boundary straddling), but yeah, it's danged difficult! Is there a way to have both a Py2 distribution and a Py3 distribution available on PyPI? -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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-specific files based on what Python version the user has.
Perhaps you should do the same--only install the Python 2 tests on
Python 2 and so on. Just make sure that the MANIFEST.in is set up to
include both versions in the source distribution. As long as you
don't install the Py2 files in Py3 or vice versa it shoudn't try to
compile the bytecode for those files.
I would be willing to do that, but I don't know how, and so far my searching
hasn't yielded anything useful besides this mailing list.
Do this do what you want:
#setup.py
import sys
from distutils.core import setup
package_data = {'enum': [...]}
if sys.version_info = (3,0):
package_data['enum'].append( 'test/py3_test_enum.py')
else:
package_data['enum'].append( 'test/py2_test_enum.py')
setup(package_data = package_data, ...)
Cool!
Is there a way to have files renamed? Ideally the installed package would just
have enum.py, test_enum.py, and not
py2_enum.py and py2_test_enum.py
Am I making this too complicated? Can I just do my renaming in the setup.py
script before calling the setup function?
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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 the user has.
Perhaps you should do the same--only install the Python 2 tests on
Python 2 and so on. Just make sure that the MANIFEST.in is set up to
include both versions in the source distribution. As long as you
don't install the Py2 files in Py3 or vice versa it shoudn't try to
compile the bytecode for those files.
I would be willing to do that, but I don't know how, and so far my searching
hasn't yielded anything useful besides this mailing list.
Do this do what you want:
#setup.py
import sys
from distutils.core import setup
package_data = {'enum': [...]}
if sys.version_info = (3,0):
package_data['enum'].append( 'test/py3_test_enum.py')
else:
package_data['enum'].append( 'test/py2_test_enum.py')
setup(package_data = package_data, ...)
Cool!
Is there a way to have files renamed? Ideally the installed package would just have enum.py, test_enum.py, and not
py2_enum.py and py2_test_enum.py
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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
|
|- py2_enum.py
|
|- py3_enum.py
|
|- test /
|- test_enum.py
|
|- py2_test_enum.py
|
|- py3_test_enum.py
__init__ and test_enum are both smart enough to pull in the correct code
when imported. The issue I am having is this:
--8--
ethan@hydra:~$ sudo easy_install enum34
[sudo] password for ethan:
Searching for enum34
Reading http://pypi.python.org/simple/enum34/
Best match: enum34 0.9
Downloading
http://pypi.python.org/packages/source/e/enum34/enum34-0.9.zip#md5=4717b8c328083d816b3b987f24446ad8
Processing enum34-0.9.zip
Writing /tmp/easy_install-sB55B5/enum34-0.9/setup.cfg
Running enum34-0.9/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-sB55B5/enum34-0.9/egg-dist-tmp-qUYAv5
SyntaxError: ('invalid syntax',
('build/bdist.linux-x86_64/egg/enum/py3_enum.py', 211, 43, 'def
__call__(cls, value, names=None, *, module=None, type=None):\n'))
SyntaxError: ('invalid syntax',
('build/bdist.linux-x86_64/egg/enum/test/py3_test_enum.py', 630, 47, '
class AutoNumberedEnum(Enum, metaclass=auto_enum):\n'))
zip_safe flag not set; analyzing archive contents...
SyntaxError: ('invalid syntax',
('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/py3_enum.py',
211, 43, 'def __call__(cls, value, names=None, *, module=None,
type=None):\n'))
SyntaxError: ('invalid syntax',
('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/test/py3_test_enum.py',
630, 47, 'class AutoNumberedEnum(Enum, metaclass=auto_enum):\n'))
Adding enum34 0.9 to easy-install.pth file
Installed /usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg
Processing dependencies for enum34
Finished processing dependencies for enum34
--8--
distutils is trying to load the py3 versions, which of course fails on a py2
install. The package installs successfully anyway, but if I were a user I
would be wondering if the install was trustworthy.
It seems to me that I need to either have distutils only install the version
appropriate files, or to not try to scan the version inappropriate files,
but at this point I do not know how to do either.
Any pointers would be greatly appreciated.
That's odd. I work on a package that ships Python 2 and Python 3
versions of some modules and I have never seen this problem before.
Perhaps you could post your setup.py?
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 the user has.
Perhaps you should do the same--only install the Python 2 tests on
Python 2 and so on. Just make sure that the MANIFEST.in is set up to
include both versions in the source distribution. As long as you
don't install the Py2 files in Py3 or vice versa it shoudn't try to
compile the bytecode for those files.
I would be willing to do that, but I don't know how, and so far my searching hasn't yielded anything useful besides this
mailing list.
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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
|
|- py3_enum.py
|
|- test /
|- test_enum.py
|
|- py2_test_enum.py
|
|- py3_test_enum.py
That's odd. I work on a package that ships Python 2 and Python 3
versions of some modules and I have never seen this problem before.
Perhaps you could post your setup.py?
--8 -- setup.py
-
from distutils.core import setup
long_desc = open('enum/enum.rst').read()
setup( name='enum34',
version='0.9',
url='https://pypi.python.org/pypi/enum34',
packages=['enum'],
package_data={
'enum':[
'enum.rst',
'enum.pdf',
'test/test_enum.py',
'test/py2_test_enum.py',
'test/py3_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='et...@stoneleaf.us',
classifiers=[
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Programming Language :: Python',
'Topic :: Software Development' ],
)
--8 -- setup.py
-
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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 http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] complicated setup
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 notice that the install was successful. I'm mostly concerned for users getting the scary messages. -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] error using easy_install
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:
package_dir={'enum':''},
When I change it to:
package_dir={'enum':'.'},
then the install succeeds. I would probably just make an 'enum' subdir,
move the files into it, and be done with it ('setup.py' isn't logically
part of the package: it is in the wrapper).
I went with the latter solution, which worked fine. Thanks!
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] complicated setup
Here's my file layout:
root /
|- setup.py
|
|- enum /
|- __init__.py
|
|- py2_enum.py
|
|- py3_enum.py
|
|- test /
|- test_enum.py
|
|- py2_test_enum.py
|
|- py3_test_enum.py
__init__ and test_enum are both smart enough to pull in the correct code when
imported. The issue I am having is this:
--8--
ethan@hydra:~$ sudo easy_install enum34
[sudo] password for ethan:
Searching for enum34
Reading http://pypi.python.org/simple/enum34/
Best match: enum34 0.9
Downloading
http://pypi.python.org/packages/source/e/enum34/enum34-0.9.zip#md5=4717b8c328083d816b3b987f24446ad8
Processing enum34-0.9.zip
Writing /tmp/easy_install-sB55B5/enum34-0.9/setup.cfg
Running enum34-0.9/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-sB55B5/enum34-0.9/egg-dist-tmp-qUYAv5
SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/py3_enum.py', 211, 43, 'def __call__(cls, value,
names=None, *, module=None, type=None):\n'))
SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/test/py3_test_enum.py', 630, 47, 'class
AutoNumberedEnum(Enum, metaclass=auto_enum):\n'))
zip_safe flag not set; analyzing archive contents...
SyntaxError: ('invalid syntax', ('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/py3_enum.py', 211,
43, 'def __call__(cls, value, names=None, *, module=None, type=None):\n'))
SyntaxError: ('invalid syntax',
('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/test/py3_test_enum.py', 630, 47, 'class
AutoNumberedEnum(Enum, metaclass=auto_enum):\n'))
Adding enum34 0.9 to easy-install.pth file
Installed /usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg
Processing dependencies for enum34
Finished processing dependencies for enum34
--8--
distutils is trying to load the py3 versions, which of course fails on a py2 install. The package installs successfully
anyway, but if I were a user I would be wondering if the install was trustworthy.
It seems to me that I need to either have distutils only install the version appropriate files, or to not try to scan
the version inappropriate files, but at this point I do not know how to do either.
Any pointers would be greatly appreciated.
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] error using easy_install
My setup.py:
-- 8 --
from distutils.core import setup
long_desc = open('enum.rst').read()
setup( name='stoneleaf.enum',
version='1.0.1',
url='https://pypi.python.org/pypi/stoneleaf.enum',
packages=['enum'],
package_dir={'enum':''},
package_data={'enum':['enum.rst', 'enum.pdf', 'test/test_enum.py',
'test/py2_test_enum.py', 'test/py3_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='et...@stoneleaf.us',
classifiers=[
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Programming Language :: Python',
'Topic :: Software Development' ],
)
-- 8 --
Error trying to install it with easy_install after uploading it to PyPI:
ethan@hydra:~$ sudo easy_install stoneleaf.enum
Searching for stoneleaf.enum
Reading http://pypi.python.org/simple/stoneleaf.enum/
Best match: stoneleaf.enum 1.0.1
Downloading
http://pypi.python.org/packages/source/s/stoneleaf.enum/stoneleaf.enum-1.0.1.zip#md5=c41abd7ad04f11e8b545cfca7758a4f2
Processing stoneleaf.enum-1.0.1.zip
Writing /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/setup.cfg
Running stoneleaf.enum-1.0.1/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/egg-dist-tmp-IpvhLD
error: Setup script exited with error: can't copy 'num.rst': doesn't exist or
not a regular file
There is no 'num.rst' file in the package -- it should be 'enum.rst'.
Any ideas? Is this the right place to post?
--
~Ethan~
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
