pmxbot IRC Log Viewer

[06:12:41] <agronholm> could somebody tell me what is the preferred method du jour to declare conditional dependencies in setup() using setuptools 27?

[06:15:19] <agronholm> "cffi >= 1.8.1 ; sys_platform in ('linux', 'win32')" <- does not work, I get a parse error

[06:16:52] <agronholm> wasn't this supposed to have been fixed in setuptools long ago?

[06:30:57] <ronny> agronholm: the conditions go to extras_require={":sys_platform in ('linux', 'win32')": ["cffi >= 1.8.1"]

[06:31:23] <agronholm> ronny: that's the old, deprecated method isn't it

[06:31:33] <agronholm> also how do I do the same with setup_requires?

[06:31:52] <agronholm> I need to put conditionals there since pip doesn't support pyproject.toml yet

[06:32:17] <agronholm> wasn't setuptools supposed to use the requirements parsing code from the "packaging" library now?

[06:32:42] <ronny> agronholm: doesnt mean its integrated all over the place, also its kind of useless on all systems with older setuptools

[06:32:56] <pombreda> ronny: extra requires is not the old way

[06:33:11] <ronny> pombreda: ?

[06:33:12] <agronholm> it's certainly not the new way either

[06:33:27] <pombreda> ronny: sry, I meant agronholm :)

[06:33:51] <pombreda> agronholm: this is for now the way :)

[06:34:32] <agronholm> but I don't understand why – setuptools is supposed to be using the requirements parsing from packaging, isn't it?

[06:34:37] <agronholm> and not the legacy code

[06:34:44] <pombreda> agronholm: I have an example and a bug related to this in https://github.com/pypa/pip/issues/3958

[06:34:59] <ronny> agronholm: atm there is exactly one single person maintaining setuptools on spare dimers of time

[06:35:05] <ronny> *dimes

[06:35:53] <agronholm> ronny: I'm not complaining about progress being too slow, I'm just wondering because according to the changelog this change was supposed to have taken place already

[06:37:01] <agronholm> but clearly this seems like something I need to look into

[06:38:30] <agronholm> hmmm...looks like pkg_resources subclasses packaging.requirements.Requirement

[06:39:20] <agronholm> but implements its own parsing? wth?

[06:40:20] <ronny> possibly a regression

[06:40:41] <agronholm> well...packaging's Requirement can't parse that either

[06:40:50] <agronholm> so I'm wondering what's up

[06:48:45] <agronholm> "cffi >= 1.8.1 ; sys_platform == 'linux' or sys_platform == 'win32'" <- this works

[06:48:59] <agronholm> I need to double check that my earlier specifier is valid

[06:51:00] <pombreda> agronholm: I would be interested to know if when you build a wheel with this, you can actually pip install <path to the wheel>

[06:51:42] <agronholm> pombreda: afaik the generated wheels will have identical metadata to those generated using extras_require

[06:52:23] <pombreda> agronholm: possibly, but I am tracking a bug related to pip handling this :P

[06:52:37] <agronholm> are you saying the metadata is different?

[06:52:52] <agronholm> because in my experience pip does handle conditional install dependencies in wheels

[06:53:10] <pombreda> agronholm: can't say yet for now, that's on my todo for today in pip 3598 above.

[06:54:11] <pombreda> but my issue is that is does not for the conditional lxml version install based on a win/linux/mac marker I referenced in the ticket

[06:54:18] <pombreda> with the latest pip/wheel

[06:54:57] <pombreda> agronholm: so if yours works, that would be a good input for my investigation in 3598

[06:55:31] <agronholm> pombreda: if you change it to platform_system == 'Linux' does it work then?

[06:56:04] <agronholm> pombreda: I just looked btw and that requirement is wrong

[06:56:34] <agronholm> you're supposed to write "linux" in sys_platform, not linux in "sys_platform"

[06:56:48] <agronholm> although not even that

[06:57:19] <agronholm> you only want to install on Linux, right? try the platform_system trick then.

[06:57:52] <pombreda> agronholm: this is what I used yesterday, I pushed the current variant for tests. It works fine as it is with a pip -e . (aka setup invocation). Not when installing a wheel.

[06:58:09] <ronny> hmm

[06:58:16] <pombreda> agronholm: platform_system trick " ?

[06:58:26] <agronholm> pombreda: platform_system == 'Linux'

[06:58:34] <agronholm> on linux it will always be "Linux"

[06:58:40] <agronholm> so you can do that simple check

[07:01:03] <agronholm> too bad PEP 508 does not contain a single example of using "in" or "not in"

[07:02:47] <pombreda> agronholm: ':"Linux" in sys_platform': ['lxml == 3.6.4'], works. You rocok !

[07:02:54] <pombreda> *Rock

[07:02:59] <agronholm> you don't need to use "in"

[07:03:08] <agronholm> just sys_platform == "Linux" will do

[07:03:25] <agronholm> it will never be anything but "Linux", regardless of python version

[07:04:02] <agronholm> and of course I meant platform_system == "Linux"

[07:04:03] <pombreda> no linux2 shenannigan then :P

[07:04:07] <agronholm> yes

[07:04:11] <[Tritium]> wait isnt it always linux2, unless you run python 1.6 on linux 3 or 4

[07:04:24] <agronholm> [Tritium]: it's linux2 on python 2

[07:04:30] <agronholm> sys_platform that is

[07:04:38] <[Tritium]> cpython is hard coded as of 2.0 and on to always return linux2 on any linux

[07:04:38] <agronholm> platform_system is always Linux

[07:05:08] <[Tritium]> prior to 2.0 it returned the actual kernel major version. My 16.04 box running 1.5.2 would return linux4

[07:05:16] <agronholm> [Tritium]: on python 3 it returns "linux"

[07:05:24] <agronholm> on python 2, "linux2"

[07:05:33] <agronholm> that's why platform_system should be preferred

[07:06:55] <agronholm> this would be so much easier if setuptools documented how to declare conditional dependencies

[07:07:45] <avmo> Hi guys, I have a doubt on PEP 440 supported versioning and setuptools_scm package. The version of my package looks like this now, '0.0.2a2.dev86+n5920d852ddde.d20160909' instead of just '0.0.2a2'. If I upload it build and pypi, will it get rid of the the local version suffix?

[07:08:03] <agronholm> no, it will reject it

[07:08:28] <agronholm> that version means you have a dirty working directory

[07:08:44] <avmo> Okay.

[07:08:48] <agronholm> you really should not be uploading such versions to pypi anyway

[07:09:23] <pombreda> so what is platform.system() on Mac?

[07:09:30] <agronholm> pombreda: Darwin

[07:09:32] <avmo> So if I commit and add a tag and then the version will just look clean. Is that so?

[07:10:04] <agronholm> avmo: yes

[07:10:21] <avmo> @agronholm, Thanks! :D

[07:10:22] <agronholm> personally I never release anything below 1.0.0

[07:10:53] <agronholm> unless I strongly feel there is tangible benefit for letting people test libraries with unstable APIs

[07:11:57] <avmo> I am just a contributor. The versioning is not upto me. I just want to make sure how PEP 440 works with packaging.

[07:12:37] <[Tritium]> agronholm: what does 1.0 even mean anymore? not much to pretty much anyone

[07:12:52] <agronholm> [Tritium]: if your project uses semantic versioning, it sure does

[07:13:02] <[Tritium]> semver is a lie, dont use it

[07:13:05] <agronholm> it means your API is stable and will not break before the next major version

[07:13:57] <[Tritium]> Thats a total lie. If you change anything, it MIGHT break the api. Which means every release is a new major version number. Unless you are releasing browsers, thats rarely acceptable

[07:14:19] <agronholm> [Tritium]: if you're unable to work with semantic versioning, you indeed should not be doing that

[07:14:25] <agronholm> I don't have that problem

[07:14:46] <agronholm> you define a public API and you make an effort to keep it backwards compatible within the same major release

[07:15:02] <[Tritium]> I also use a huge ammont of software, thats activly developed, that is sub 1.0 for... ten years

[07:15:10] <agronholm> so?

[07:16:13] <[Tritium]> version numbers are literally meaningless. Its even worse when you try to apply meaning universally to version numbers and no two humans do it the same way (even with semver)

[07:16:47] <[Tritium]> And to top this all off... there are IDEs out there that have tooling that START your project at 1.0

[07:16:54] <agronholm> there are no absolute certainties but a project that declares to adhere to semantic versioning is far less likely to break when upgrading within the same major version

[07:17:19] <mgedmin> or at least you get to declare that the breakage is a bug :)

[07:17:21] <pombreda> agronholm: thank you :) you fixed two tickets thanks tp this :)

[07:17:21] <[Tritium]> semver bills itself as a garentee.

[07:17:22] <tdsmith> some lies are useful

[07:17:27] <agronholm> pombreda: yw

[07:17:52] <agronholm> as I said, semver is a promise and one can only do their best to keep that promise

[07:18:14] <[Tritium]> Then why make the promise? all you are doing is lieing to users

[07:18:23] <agronholm> what am I lying about?

[07:18:45] <agronholm> declaring semver is promising that I will do my best to keep the releases compatible until the next major version

[07:18:52] <agronholm> where is the lie in that?

[07:19:06] <[Tritium]> If you declare you are using semver, you either can never release a 1.0, or you knowingly break the absolute garentee of no breakage

[07:19:34] <agronholm> [Tritium]: have you been listening to ANYTHING I've been saying?

[07:19:45] <tdsmith> this is the "nothing is ultimately knowable" school of thought

[07:19:48] <avmo> So it is supposed to be MAJOR.MINOR.PATCH. Quoting from semver.org "MAJOR version when you make incompatible API changes". So if the project is always backward compatible, then there is no version 1.0.0 right?

[07:19:55] <[Tritium]> agronholm: yes. and i have heard it all before.

[07:20:13] <mgedmin> semver MAJOR = 0 means "no compatibility guarantees at all, use at your own risk"

[07:20:23] <agronholm> mgedmin: that it does

[07:20:25] <mgedmin> backwards-compat guarantees _start_ with version 1.0.0

[07:20:28] <[Tritium]> avmo: semver also has special rules for 0.

[07:20:40] <mgedmin> no breaking changes or your money back

[07:21:04] <agronholm> avmo: if a project is always backwards compatible then there won't be version 2.0

[07:21:28] <agronholm> also no 0.x releases

[07:23:04] <pombreda> :D

[07:23:28] <pombreda> bikeshedding versioning schemes is always fun, is it?

[07:23:40] <agronholm> who's doing that?

[07:24:09] <pombreda> :D

[07:24:18] <agronholm> no, really

[07:24:22] <avmo> agronholm, Makes sense. Well projects like scipy do upload to pypi eventhough they are at 0.17.1. So MAJOR=0 is not a bad thing

[07:24:49] <agronholm> avmo: major=0 means that the API could break in 0.17.2

[07:24:59] <avmo> :)

[07:25:24] <mgedmin> speaking of version schemes

[07:25:25] <[Tritium]> Semver /in principal/ is a decent idea, but the fact that it provides promises, and that no two people implement it the same way, using semver *as advertised* is a morally questionable at best.

[07:25:28] <pombreda> agronholm: I meant by this that a discussion on versioning schemes and any guarantee it provides it pointless. The only thing guarantee are the authors best efforts

[07:25:44] <mgedmin> I've this strong internal belief that dropping support for a Python version (e.g. 2.6 or 3.2) means you need to bump MINOR

[07:25:51] <mgedmin> but I'm not sure it squares with semver

[07:26:34] <agronholm> mgedmin: ask yourself this: if someone using either of those python versions does an upgrade within the same major version, will things break?

[07:26:52] <[Tritium]> mgedmin: it depends on how you define API. the api on which your library runs, then major. if the api that you provide, then minor.

[07:27:41] <[Tritium]> mgedmin: in this particular case, i see more libraries incrementing major when they drop support than i see minor.

[07:27:58] <agronholm> which would be the correct choice IMHO

[07:28:54] <mgedmin> yeah, thought so

[07:48:59] <pombreda> mgedmin: hey :) .... have you ever considered running restview on every Pypi package to asses the poor state to long descriptions? or would that become a lesser issue with warehouse?

[07:49:20] <pombreda> my heart bleeds each time I see broken ReST in long descriptions on Pypi

[07:49:29] <mgedmin> I file bugs when that happens

[07:49:34] <pombreda> *to assess

[07:49:35] <mgedmin> restview is probably not the best tool for this tbh

[07:49:52] <pombreda> true

[07:49:54] <mgedmin> https://github.com/pypa/readme_renderer has this 'setup.py check' thing

[07:50:24] <mgedmin> I like restview because it lets me preview for semantic errors, not just syntax errors

[07:50:46] <mgedmin> but this is an AI-complete thing

[07:50:54] <mgedmin> and so cannot be automated

[07:54:40] <pombreda> mgedmin: yep. so at least the problem may just go away with the readme_renderer. :) thanks

[07:55:09] <mgedmin> huh, readme_renderer ... it used to be called just readme

[07:55:14] <pombreda> :)

[07:55:19] <mgedmin> do I need to update my install_requires=['readme'] ?

[07:55:39] <tdsmith> comments welcome on this proposal that Homebrew stops relying on system Python: https://github.com/Homebrew/brew-evolution/pull/12

[07:55:41] <mgedmin> (yes, I should)

[07:56:03] <mgedmin> strangely readme has a newer version (0.7.1) than readme_renderer (0.7.0)

[07:56:33] <pombreda> mgedmin: I was about to say this :P

[07:57:01] <mgedmin> oh, someone sent me a PR to switch to readme_renderer back in January, and I merged it

[07:57:40] <mgedmin> this is called "stateless package maintenance" where I don't remember what's going on with my packages and just do stuff as it comes up ;)

[07:58:08] <pombreda> mgedmin: :D a privilege of the braves

[07:59:00] <pombreda> receive a PR. great the tests still pass. let's merge first. we can review later

[08:00:23] <mgedmin> oh, I do review -- I just forget all about it the next day

[08:01:40] <mgedmin> (also, wasn't readme renamed _because_ some user filed a bug against restview, for failing installation due to an anaconda-created README file in site-packages on Windows conflicting with the readme/ package directory?)

[08:02:38] <mgedmin> lol my memory

[08:03:01] <mgedmin> (I've made myself a list of packages I'm maintaining at http://projects.gedmin.as/ just so I won't forget that I'm maintaining them)

[08:12:45] <pombreda> mgedmin: lol

[08:13:57] <pombreda> mgedmin: may I suggest you make a package of this list too? with only a setup.py that will just install them all? :D

[08:14:22] <mgedmin> why?

[08:15:14] <pombreda> mgedmin: just for the fun of it :P

[08:15:20] <pombreda> no serious reason

[08:55:18] <[Tritium]> if you pip install toga with no dependencies, nothing will be installed. The toga package is a meta-package - its just a setup.py file

[08:55:44] <[Tritium]> its like a distro metapackage; existing only to depend on other packages

[09:50:01] <ionelmc> mgedmin: i want a list like that. how do you build it?

[09:50:48] <mgedmin> https://github.com/mgedmin/project-summary

[09:51:20] <ionelmc> ah

[09:51:35] <ionelmc> i wonder if there's way to set it up without any jenkins

[09:51:44] <mgedmin> all it needs is a directory with a bunch of git clones

[09:52:10] <mgedmin> I piggy-backed on my jenkins since I already had it

[09:53:56] <mgedmin> all it needs is a pull request to make some things configurable, e.g. https://github.com/mgedmin/project-summary/blob/master/summary.py#L35

[09:54:34] <mgedmin> heh https://github.com/mgedmin/project-summary/blob/master/summary.py#L213-L214

[09:56:02] <mgedmin> https://github.com/mgedmin/project-summary/blob/master/summary.py#L616

[09:57:58] <mgedmin> anyway, I'm happy to make it generic if there's interest (i.e. someone files a github issue/PR asking for it)

[10:20:36] <pombreda> very neato :)

[10:21:29] <pombreda> [Tritium]: was this a question?

[10:22:21] <[Tritium]> No, someone was mentioning doing something along those line for fun... Im just pointing out its used in production for at least one project

[10:23:14] <pombreda> [Tritium]: ah, thanks. yes, I mentioned something like that on the wheels-builder list the other day and again today

[10:23:58] <pombreda> [Tritium]: I first used that based on the advice of mgedmin several years ago

[10:24:24] <pombreda> let me reply on list with that example

[10:28:27] <pombreda> [Tritium]: there you go: https://mail.python.org/pipermail/wheel-builders/2016-September/000226.html

[10:30:56] <[Tritium]> Cheers

[10:36:50] <pombreda> :)

[16:06:54] <underyx> setuptools 😿

[19:25:49] <Siecje> I've downloaded a tar (in this case matplotlib) and I have done `pip install .` inside the directory after extracting. It fails with an error that setup.py egg_info failed.

[19:25:50] <Siecje> Are eggs still being used?

[19:26:15] <Siecje> I also tried to do setup.py build and setup.py install directly but I can't import it and it doesn't show up in pip freeze

[19:27:31] <ngoldbaum> Siecje: pastebin the error?

[19:27:45] <ngoldbaum> Siecje: matplotlib has binary wheels for most platforms, FWIW

[19:28:01] <Siecje> https://dpaste.de/06DR

[19:28:20] <Siecje> ngoldbaum: The releases from yesterday are not on PyPI yet

[19:28:27] <ngoldbaum> Siecje: yeah, matpltolib can't find libfreetype or libpng

[19:28:36] <ngoldbaum> Siecje: tom caswell is building them as we speak, patience :)

[19:28:46] <Siecje> How do you know?

[19:28:53] <ngoldbaum> he said on matplotlib-dev

[19:29:57] <ngoldbaum> Siecje: if you want to build matplotlib from source, you need to install libfreetype and libpng first

[19:30:10] <Siecje> What is the deal with eggs when I specify a local directory?

[19:30:13] <ngoldbaum> or tell matplotlib's setup.py where they're installed

[19:30:19] <ngoldbaum> oh i have no idea

[19:30:25] <ngoldbaum> but the egg part isn't the important bit

[19:30:36] <ngoldbaum> matplotlib's setup.py is searching to see if it can find the hard dependencies

[19:30:40] <ngoldbaum> and aborts when it can't

[19:30:50] <ngoldbaum> the same thing would happen if pip tried to build a wheel

[19:31:07] <ngoldbaum> i think you need the "wheel" package installed for pip to build wheels?

[19:32:05] <Siecje> If the local directory is an hg repo then I get see hg in pip freeze https://dpaste.de/2f7V

[19:32:19] <Siecje> That's a terrible example because of that wierd hg problem I have but yeah

[19:48:42] <frewsxcv_> Looks like a cyclic import issue? http://build.servo.org/builders/linux-rel/builds/3114/steps/compile/logs/stdio

[19:49:59] <frewsxcv_> Ah. https://github.com/pypa/setuptools/commit/a6524a5c0d40aedbaa06eb41c70990c44a1dfd15#diff-7a57001e25187bbd1b274c7de202cf4c

[21:34:48] <pombreda> frewsxcv_: that was timely :)

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 9th of September, 2016