pmxbot IRC Log Viewer

[10:14:10] <ronny> dstufft: evil early ping, should we get a wiki for python packaging documentation, i dont think a sphinx thing will propperly cut it

[10:19:54] <[Tritium]> Has it been suggested in the past for virtualenv, when run on windows, just set the TCL_LIBRARY envvar in the activate script? every user who does tkinter on windows has to do this manually, and it seams like something the tool could trivially do automatically

[10:35:14] <[Tritium]> Looking at the code, perhaps it is non-trivial to make the changes to automattically set that

[11:42:24] <ronny> [Tritium]: i wonder if it would be sensible for site.py

[13:37:46] <angular_mike> hello

[13:38:25] <angular_mike> is it possible to install pip offline?

[13:43:42] <Wooble> angular_mike: what do you mean by that? If you have a source dist already, sure.

[13:44:40] <angular_mike> I have a VM with no internet, but I can move files to it

[13:44:57] <angular_mike> I need to somehow get pip installed on it

[13:45:47] <Wooble> yeah, just grab the source from https://pypi.python.org/pypi/pip and run "setup.py install" from the source dir.

[13:46:38] <Wooble> https://pip.pypa.io/en/latest/installing.html#install-pip also has instructions to use get-pip.py with local copies of pip and setuptools.

[13:49:26] <angular_mike> ok, thanks

[14:04:31] <trash> ahoi, I've got https://github.com/syseleven/python-cloudutils/blob/master/requirements.txt which contains https://github.com/syseleven/python-cloudutils-libs as dependency. When doing the pip install -e git:// manually it works, but when doing pip install -e git://github.com/syseleven/python-cloudutils#egg=syseleven.cloudutils it cannot find the libs because it only searches on pypi. What am I doing wrong? ;-)

[14:06:36] <trash> Also doing pip install -r requirements.txt works (fetching the proper dep via github)

[14:38:57] <trash> Hm, https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L150 might be the problem...

[14:40:20] <ionelmc> trash: pbr just cleans it up

[14:40:29] <ionelmc> they probably have their own package index

[14:41:13] <ionelmc> cause urls are not supported for install_requires

[14:43:03] <trash> Hmm, so there probably is no other solution than use pypi (or using devpi)?

[15:12:32] <ionelmc> trash: nope, also, this might be interesting read https://caremad.io/2013/07/setup-vs-requirement/

[15:19:17] <tomprince> ronny: Why won't sphinx cut it?

[15:22:00] <ronny> tomprince: not a wiki

[15:22:15] <ronny> tomprince: sphinx is more of a edit in a good text editor thing

[15:23:17] <tomprince> ronny: I'm still not sure why that is a problem?

[15:24:35] <ronny> tomprince: accessibility and edit via web

[15:24:46] <ronny> sphinx is crappy there, thats a barrier

[15:25:28] <ionelmc> ronny: IMO the problem is that there are too much docs

[15:25:53] <ronny> ionelmc: step one create one canonical place that covers all tools and is easyly fixed up by anyone

[15:25:59] <ionelmc> IOW, there's too much complexity, you can't have "simple docs"

[15:26:24] <ronny> then one can go around killing docs, and market the new nice place

[15:26:53] <tomprince> ronny: https://packaging.python.org/en/latest/ ?

[15:27:51] <ionelmc> ronny: ok, lets take a concrete example, something that irks me - there are so many ways presented here https://packaging.python.org/en/latest/single_source_version.html

[15:28:07] <ionelmc> you don't have a clear perspective of what's the best thing to do

[15:28:19] <ionelmc> ronny: how would a wiki solve that specific issue?

[15:28:48] <ionelmc> i'm genuinely curious

[15:29:22] <ronny> tomprince: now how would a random person go about fixing a issue with that ?

[15:29:46] <ronny> tomprince: step one is find a fscking scm repo and clone it, fork it commit a change, push and make a pull request

[15:29:57] <tomprince> ronny: Click the "Edit on github" button, then the little pencil.

[15:30:07] <ronny> ionelmc: the wiki is simply to have a collaboration platform with next to no barrier

[15:30:27] <ronny> tomprince: needs a github account

[15:30:58] <ionelmc> ronny: i don't think making a fork and a PR is a too high barrier to contribution

[15:31:10] <tomprince> To a first approximation, everybody has a github account.

[15:31:15] <ronny> ionelmc: it is

[15:31:24] <ionelmc> but arguing with the maintainers of said guide is a barrier

[15:31:39] <ionelmc> you want that, they want something else

[15:32:04] <ionelmc> so from *that* perspective, how does a wiki improve anything?

[15:32:15] <ionelmc> how would you have quality control with a wiki?

[15:33:10] <ionelmc> i'm not saying it's a bad idea, i'm just asking a hard question :-)

[15:37:04] <ronny> ts a wiki, you dont have direct quality controll, people are the control

[15:39:32] <ronny> ionelmc: a wiki at first is editable for anyone

[15:39:47] <ronny> also there is need for one consistent storey thats listd everywhere and is *complete*

[15:40:07] <ronny> i.e. developer perspective, pypi user perspective, package maintainer perspective

[15:42:26] <tdsmith> Homebrew's experience was that people would drive by and leave incorrect helpful advice on our wiki that we wouldn't get a notification about and would have to correct at whatever later date we noticed it; we ended up protecting it to maintainers and then just made it part of our source tree so we could take PRs against it

[15:44:18] <ronny> tdsmith: i see, hmm, then i miht be wrong after all

[15:44:48] <ronny> dstufft: can we get all documentation locations to point to one canonical one?

[15:45:05] <ronny> and have them all big red warnings that they are outdated and potentially dangerous?

[15:47:02] <tomprince> ronny: I think the correct response to that is PRs welcome.

[15:47:28] <ronny> tomprince: most of the alternative doc locations people find are NOT in git

[15:47:42] <ronny> so PR welcome is a completely useless resonse

[15:48:57] <tomprince> ronny: What docs aren't in git?

[15:49:04] <tomprince> (Or hg)

[15:49:35] <ronny> tomprince: allmost all of the legacy docs around, may outdated and wrong

[15:50:22] <ronny> hmm, let me find the link the sqlalchemy author showed me again

[15:51:45] <tomprince> I wonder how many of them are actually pypa controlled?

[15:52:05] <ronny> tomprince: not that many, but i think some links are on python.org docs

[15:53:01] <ronny> hmm

[15:53:09] <ronny> i cnat find the link off-hand

[15:53:37] <xafer> I'm not in favor of the wiki but concerning outdated doc, this one is not helping: https://setuptools.pypa.io/en/latest/

[15:54:32] <tdsmith> version 5's a little stale, huh

[15:54:32] <ronny> ouch

[15:55:15] <tomprince> ronny: If it is the python documentation itself, I guess a patch against python.

[15:55:33] <tomprince> If it is the website, https://github.com/python/pythondotorg maybe?

[15:55:41] <tomprince> Elsewhere, I don't know.

[15:55:55] <ronny> i think we need a few more people with documentation "fetish"

[15:56:53] <The-Compiler> I have latex.. err, LaTeX-fetish, does that count?

[15:58:01] <tomprince> ronny: It sounds like you have a bit of that.

[16:00:41] <ronny> The-Compiler: evne tho its shiny and skintight its not fit for this community :P

[16:01:04] <pf_moore> ronny: IMO the big problem (ignoring out of date setuptools docs which definitely needs fixing :-() is that there is no correct answer to document

[16:01:07] <ronny> tomprince: well, itscimplicated :P

[16:01:43] <ronny> pf_moore: there is something to document and thats how to geet started correctly stories, and how to move to the new process correclty storries

[16:02:01] <ronny> known good simple examples people can extrapolate from with explanations of details

[16:02:45] <ronny> tomprince: hmm, the current https://packaging.python.org needs quite some work :/

[16:03:02] <pf_moore> ronny: As usual, PRs welcome :-)

[16:03:20] <pf_moore> One thing I know causes some contention though is the single-sourcing the version example you gave above

[16:03:39] <pf_moore> The problem there is that there *is* no good answer that anyone's found

[16:04:06] <pf_moore> Just because people don't like "hard code it in 2 places" doesn't mean it's the wrong answer. And so we get complicated lists of options :-(

[16:04:24] <ronny> pf_moore: there is need for good code bits that handle it

[16:05:17] <ronny> (in some of the projects i maintain i had to opt for different shemes

[16:05:39] <ronny> pf_moore: people need examples off known good code that makes setup.py parse the other place instead

[16:05:59] <pf_moore> ronny: But nobody's offered any...

[16:06:03] <pf_moore> As an occasional author of that doc, I don't know how to do it so I can't give an answer...

[16:06:07] <ronny> https://bitbucket.org/hpk42/apipkg/src/692dca5b661038cd7a514f06dd5a00aad71a5419/setup.py?at=default#cl-11

[16:06:40] <ronny> (i just made that this moring since for that package it was decided not to have setup time dependencies)

[16:06:52] <pf_moore> ronny: That approach was suggested at one point and caused flamewars from people who hit issues with it.

[16:07:29] <pf_moore> This is the wiki problem - people keep offering a solution that works for them, and others keep changing it because it doesn't suit their need

[16:07:32] <ronny> pf_moore: got links?

[16:07:40] <pf_moore> Nope, sorry.

[16:08:00] <ronny> there also is a variant using ast around

[16:08:03] <pf_moore> There might be some PRs for the packaging guide that show the hiostory

[16:08:07] <ronny> (used in flask for example

[16:09:04] <pf_moore> Personally, I prefer putting the version in setup.py and not exposing it in the module API. Or if I must, hard coding it a second time there.

[16:09:13] <pf_moore> Why is that not just as good an option?

[16:10:13] <ronny> my preference is to just get it from the scm

[16:10:28] <ionelmc> everyone as a different preference :)

[16:10:28] <ronny> and have a new dev version for every commit automatically

[16:10:40] <ionelmc> *has

[16:10:52] <pf_moore> And we've now reached a point where I've successfully demonstrated that there's no consensus or best practice to document

[16:11:03] <pf_moore> :-)

[16:11:30] <ronny> pf_moore: bascially as soon as its hardcoded at 2 places, you need tools that commit changed files to the scm and tag that afterward just to deal with versions and to ensure you are

[16:12:15] <ronny> pf_moore: imho hunless you have a good reason, dont repeat yourself ^^

[16:12:26] <pf_moore> ronny: But my workflow (which is for tiny projects only) makes that much easier than the alternatives

[16:12:34] <ionelmc> ronny: bumpversion ^^

[16:13:05] <ronny> pf_moore: now however, just declaring to use the version from the scm requires no way at all to ensure you are correct ^^

[16:13:16] <pf_moore> ronny: IMO, don't invent complex solutions to simple problems (and for *my* use, duplicating is trivial)

[16:13:24] <ionelmc> ronny: i agree your setuptools_scm is better but it's not practical for all projects

[16:13:39] <ronny> ionelmc: i intend to solve that with gumby elf :P

[16:13:52] <pf_moore> Just to make it clear: I'm not trying to be confrontational, just to make the point that people have different needs and requirements

[16:14:36] <pf_moore> I got badly burned by this when I first created sampleproject - almost everything I initially added got removed because people said "but that doesn't fit my requirements"

[16:15:13] <ionelmc> pf_moore: what project?

[16:15:27] <ronny> pf_moore: with managing versions, nobody ever told me a a valid argument for not using scm metadata to get versions, only variations of 'tools suck' and 'error prone is easy'

[16:15:56] <pf_moore> ionelmc: https://github.com/pypa/sampleproject - the one used as an example in the packaging docs

[16:17:01] <pf_moore> ronny: How about "I don't put my versions in scm metadata"? Or "my scm version isn't PEP 440 compliant"? Sure, it's not good project practice, but it's real.

[16:17:07] <ionelmc> pf_moore: it's so bare!

[16:17:14] <ionelmc> put some clothes on it

[16:17:28] <ronny> pf_moore: those fit "error prone is easy"

[16:17:29] <pf_moore> ?

[16:17:34] <ionelmc> a tox.ini, some pytest conf etc

[16:17:54] <pf_moore> nope, not everyone agrees with tox or pytest. Been there, read the emails...

[16:18:01] <ionelmc> meh

[16:19:19] <ronny> pf_moore: "my scm versions are not pep440 means "im not willing to use nice tags even tough i could"

[16:19:20] <pf_moore> ronny: Fair point, but "error prone" is a funny thing. Should I care about Unicode characters in the code that defines the version? I know I'll never put any in there, and the code I need in setup.py gets a lot more complicated if I do.

[16:19:42] <ionelmc> well, i'm going the other way with cookiecutter-pylibrary - lots of "bling" and have options to generate different variations (like pytest vs nose)

[16:19:50] <ronny> pf_moore: bascially not , and document that fact

[16:20:20] <ronny> pf_moore: i'd read the version file as native string, parse with a native regex and return a native version string

[16:20:21] <pf_moore> ronny: Please remember I'm playing devil's advocate here, but you're now dictating my project development practices, not how I write my setup.py.

[16:20:37] <ionelmc> if ronny makes that grumpy package tool i could have an option for that - incidentally the file layout matches i think :)

[16:20:45] <ronny> pf_moore: yes, its sensible to do that

[16:21:03] <pf_moore> but it's out of scope for the Python packaging user guide, IMO.

[16:21:10] <ionelmc> ronny: btw, did you look at that template?

[16:21:18] <pf_moore> And that's where we started.

[16:22:05] <pf_moore> Initially I argued strongly that we should document "best practices", defining them if we didn't have an existing consensus

[16:22:11] <pf_moore> It didn't get very far.

[16:22:30] <ronny> pf_moore: there is a reason why im creating a tool that will just use them ^^

[16:22:43] <pf_moore> I would be more than happy for someone else to have a go, if they have the energy.

[16:23:46] <ronny> reminds me that i need to add a bit in setuptools-scm to teach how to parse idiotic version tags

[16:24:24] <pf_moore> ronny: Yeah, that might be useful. But I routinely hack up tiny little projects, which may or may not go anywhere. For something like that I don't *want* to set up fancy release processes yet.

[16:24:49] <pf_moore> ronny: How does setuptools-scm fare as something that can be incrementally added to a project as needed?

[16:24:59] <ronny> pf_moore: setuptools_scm is not fancy, all you need is a setup_requires entry and a keyword

[16:25:09] <pf_moore> (disclaimer: I've not looked at it, as it seems "too complex for my simple needs" to me)

[16:25:09] <ronny> basically a 3 line change in setup.py

[16:25:24] <pf_moore> setup_requires gives me nightmares, I avoid it like the plague

[16:25:56] <pf_moore> It gives easy_install permission to run

[16:26:52] <ronny> pf_moore: i tihnk you will like gumby elf, i shoul finish the develop, install and upload commands ^^ (it will upload setuptools compatible sdists, but the scm checkout wont be setuptools compatible

[16:27:35] <pf_moore> Oh, and doesn't it require me to use tags in my scm? Even for the 0.1-I-haven't-decided-if-I'll-publish-it release?

[16:30:05] <ronny> pf_moore: same as setuptools scm

[16:30:09] <ronny> no tag means 0.1.devX

[16:32:39] <pf_moore> OK, fair enough. I still doubt I'll bother, though :-)

[16:41:01] <ronny> pf_moore: that gives me the impression that you prefer error prone processes you know over new processes you dont know

[16:42:20] <pf_moore> ronny: No, I prefer minimising dependencies on additional software and only adding complexity as required.

[16:43:53] <pf_moore> ronny: And not letting easy_install / eggs anywhere near my environment (but I guess there's an approach for using setuptools_scm that doesn't need setup_requires, so that's a minor point)

[16:44:52] <pf_moore> (I'm also talking about projects with a user base that's optimistically in the range 0-10 - please understand that I'm *not* in your target audience here!)

[16:46:22] <pf_moore> The original discussion was about the packaging docs, for which I *am* in the target audience, though.

[16:47:33] <tomprince> pf_moore: Also, there is an open PR making pip take over setup_requires.

[16:47:47] <tomprince> Well, an alternative to the current setup_requires that pip controls.

[16:49:12] <ronny> pf_moore: setuptools_scm could ship a sdist command that edits itself out of setup.py on sdist, and wheels never need a setup.py

[16:49:58] <pf_moore> tomprince: Yeah, I know. I still prefer to not need setup_requires in the first place, but that PR would improve how it works a lot.

[16:50:50] <tomprince> versioneer is an option that does something similiar, but just involves putting a file in the repository.

[16:52:18] <ronny> tomprince: link?

[16:52:29] <ronny> (for the pip setup requires thing)

[16:53:11] <pf_moore> ronny: https://github.com/pypa/pip/pull/2603

[17:13:51] <dstufft> I don't think that we should close down all the project specific docs

[17:14:02] <dstufft> packaging.python.org is not a repalcement for pip's docs or setuptools docs

[17:14:18] <dstufft> it's a higher level "here's how you combine all the tools into a working thing" sort of thing

[17:14:26] <dstufft> and it's also more beginner focuses

[17:14:46] <dstufft> but getting down into the nitty gritty details on one project belongs in their respective docs

[21:14:55] <jezdez> dstufft: +1

[21:15:18] <jezdez> a “user guide” is always a good idea, with links to the canonical in-dept docs

[21:15:27] <jezdez> depth, even

Log file Viewer

Help | Karma | Search:

#pypa logs for Wednesday the 25th of March, 2015