pmxbot IRC Log Viewer

[08:33:48] <ronny> lifeless: ping?

[08:40:13] <lifeless> ronny: pong

[08:41:26] <ronny> lifeless: wrt your work on setup_requires, i devides a plan to have setuptools be able to opt out of automated easy_install invocations (adding commands to fetch/print setup_requires)

[08:43:24] <ronny> lifeless: since you already digged into such details, i'd like you to review once i set it up

[08:43:49] <lifeless> thats an interesting thing

[08:44:14] <lifeless> It's not enough for what I want - since I want setup.py's that don't need the super-careful coding style

[08:44:37] <lifeless> but I can see it being an incremental improvement in it's own right, in the absence of declarative setup_requires

[08:44:44] <lifeless> so sure, I'd be delighted to review it

[08:47:11] <ronny> lifeless: i want to get to static metadata anyway, im experimenting with it in gumby elf, but thats still far from being usable

[08:47:21] <ronny> atm all it can do is pip uninstalable develop installs

[08:47:51] <ronny> lifeless: btw, are you working on more declarative metadata for setup.py as well?

[08:47:56] <lifeless> ronny: yes

[08:49:03] <ronny> lifeless: in what contexts, and any plans to support infered metadata (i want to generate version from the scm tags)

[08:49:56] <lifeless> ronny: its getting a bit late here, need to wind down for the night,, but .. quickly ;)

[08:50:25] <lifeless> a) setup_requires, install_requires and extra_requires read from setup.cfg by the pip process itself

[08:50:37] <lifeless> [perhaps via a setuptools API, but thats code-twiddling, not a fundamental thing]

[08:50:59] <lifeless> b) pip doing the temporary installs of setup_requires needed to run setup.py install etc etc

[08:51:48] <lifeless> c) I want to support this for -e installs (so no sdist at all), regular install-a-directory (pip makes the sdist), and sdists from PyPI etc.

[08:52:07] <lifeless> ronny: I too generate versions from scm tags (thats a big part of what pbr does)

[08:52:23] <ronny> lifeless: seen setuptools_scm?

[08:52:25] <lifeless> ronny: so I'm not planning on making version declarative at this point

[08:52:53] <lifeless> ronny: we'll just use the declarative deps to bootstrap enough to run setup.py egg_info if we need a version, or install otherwise.

[08:53:01] <ronny> lifeless: thing is, i want to turn version declarative in the sdist ^^

[08:53:20] <lifeless> ronny: it is declarative in sdists

[08:53:31] <lifeless> as in there's metadata in there

[08:53:41] <ronny> lifeless: it needs code to obtain it

[08:53:43] <lifeless> pbr bundles it in statically in sdists

[08:54:19] <ronny> i avoid pbr, its a bit too openstack-ish

[08:54:25] <lifeless> I hadn't seen setuptools_scm - looks ok

[08:54:43] <lifeless> ronny: we're making it more flexible for other fokl to reuse as folk ask us to

[08:55:27] <lifeless> ronny: next release will be doing semver - http://docs.openstack.org/developer/pbr/index.html#version

[08:55:39] <ronny> lifeless: im using tox and pytest, im not doing semver ^^

[08:55:57] <lifeless> heh :)

[08:56:11] <lifeless> anyhow, you could look at how pbr captures the version into the sdist

[08:56:39] <lifeless> I don't recall the details offhand. I think its metadata-2.0, with the code to read that in setup_requires referenced code [pbr itself]

[08:57:00] <ronny> lifeless: even plain distutils sdistcaptures the version metadata

[08:57:31] <ronny> lifeless: setuptools_scm handles getting metadata from the sdist just fine, but that makes it impossible to make a plain sdist that has no setup_requires

[08:58:06] <ronny> i.e. i want to need the "setup_requires" only when im in a scm checkout/archive

[09:02:56] <lifeless> ronny: ok, so thats easy - implement https://www.python.org/dev/peps/pep-0426/#version for pip

[09:03:20] <lifeless> ronny: (and then in setuptools_scm output the file)

[09:03:34] <ronny> lifeless: as long as setup.py is needed for install, that would still need it there

[09:03:52] <lifeless> ronny: huh?

[09:04:07] <lifeless> ronny: your sdist wouldn't need setup_requires

[09:04:26] <ronny> lifeless: that means its broken unless its used with pip

[09:05:04] <lifeless> ronny: or any other metadata-2.0 supporting tool

[09:05:16] <lifeless> ronny: setuptools itself could support that, for easy_install folk

[09:06:17] <lifeless> but the migration strategy is fairly straightforward - output setup_requires until you judge the tooling support for PEP-426 is mature enough to drop it

[09:07:48] <ronny> lifeless: however as far as i see it, its possible to drop many setup_requires for sdists because the data is known and just needs to be filled in some way

[09:09:02] <lifeless> ronny: sure, as long as {set of tools the author cares about} can read it

[09:10:41] <ronny> gumby elf for example will just generate a static setup.py, egg info and metadata2.0 for a sdist, and dist_info+metadata 2.0 for a wheel

[09:11:05] <lifeless> oh right

[09:11:12] <lifeless> yes, thats one of the ideas bandied around for a while

[09:11:16] <lifeless> its interesting as a hack

[09:11:19] <lifeless> its not super clean though

[09:11:44] <lifeless> just aesthetically I mean, having setup.py in VCS be quite different to setup.py in sdist

[09:13:16] <ronny> lifeless: gumby elf has no setup.py in scm at all

[09:13:29] <ronny> (instead a key in package.json)

[09:13:45] <lifeless> what reads package.json?

[09:14:39] <ronny> gumby elf does

[09:14:53] <ronny> npm does and jspm does

[09:16:29] <lifeless> I thought npm was node specific

[09:16:45] <lifeless> and jspm is js specific too

[09:17:07] <ronny> yes

[09:17:11] <ronny> they are

[09:17:26] <ronny> but why not reuse their file?

[09:17:46] <ronny> i have spa things going on anyway, so i'll have a package.json because i need node and jspm things

[09:26:09] <lifeless> I guess the meta-build system dstufft wants added to pip could learn about that eventually

[09:26:46] <ronny> lifeless: it will, i plan to be one of the first users ^^

[09:27:21] <lifeless> well, there's no meta-build system today

[09:27:27] <lifeless> so that will need to be added first

[09:27:37] <lifeless> I'm not sure how big it will be to do that

[09:28:38] <ronny> lifeless: i suspect it will be rather small, i suggested the cli and metadata2 as interface, (the idea is it will jsut install and invoke)

[09:28:58] <lifeless> cli?

[09:29:13] <ronny> lifeless: command line interface

[09:29:24] <lifeless> ronny: duh :)I mean which one

[09:29:35] <ronny> so instead of running a python api, it would call commands, just something else instead of python setup.py

[09:29:51] <lifeless> how will it figure out that it needs to do that?

[09:30:28] <ronny> lifeless: that needs to be in the metadata ^^

[09:30:38] <lifeless> which metadata?

[09:30:47] <lifeless> Specifially I'm talking about pip install git+...

[09:32:06] <ronny> lifeless: well, the meta build system would need metadata to begin with, eventually we will know how it will look

[09:32:14] <lifeless> ah

[09:32:18] <lifeless> no - the point is that it will guess

[09:32:29] <lifeless> setup.py -> setuptools interface

[09:34:11] <ronny> lifeless: hmm, fun ambiguity then ^^

[09:35:06] <lifeless> https://pip.pypa.io/en/latest/reference/pip_install.html#build-system-interface

[09:37:51] <lifeless> thats the current non-meta interface

[09:37:59] <lifeless> the ideas AIUI is to generalise this a little

[09:38:46] <ronny> AIUI?

[09:38:52] <lifeless> as I understand it

[09:38:58] <ronny> i see

[09:41:22] <ronny> i'll work with donald on that, first i'll take a look at opting out of implied easy install

[16:10:49] <ielectric1> dstufft:

[16:10:51] <ielectric1> E _pytest.config.ConftestImportFailure: (local('/home/ielectric/dev/warehouse/lib/python3.4/site-packages/tests/conftest.py'), (<class 'py._path.local.LocalPath.ImportMismatchError'>, ImportMismatchError('tests.conftest', '/home/ielectric/dev/warehous

[16:10:53] <ielectric1> e/tests/conftest.py', local('/home/ielectric/dev/warehouse/lib/python3.4/site-packages/tests/conftest.py')), <traceback object at 0x7fe16185c808>))

[16:10:55] <ielectric1> any ideas?

[16:11:04] <ielectric1> I get that while running tox

[16:11:45] <ielectric1> http://pastie.org/10096321

[16:16:52] <iElectric> well getting around tox fixes it

[16:16:55] <iElectric> as always :)

[22:33:59] <iElectric> blah

[22:34:05] <iElectric> pytest-dbfixtures is giving me hell

[22:34:13] <iElectric> creating configuration files ... ok

[22:34:15] <iElectric> creating template1 database in /tmp/postgresqldata.5433/base/1 ... FATAL: configuration file "/tmp/postgresqldata.5433/postgresql.conf" contains errors

[22:34:17] <iElectric> child process exited with exit code 1

[22:42:11] <iElectric> meh, I've had my fix

[22:42:22] <iElectric> I'll commit what I have and get back to tests someday

[22:59:13] <dstufft> oh

[22:59:15] <dstufft> didn't see this

[22:59:27] <dstufft> iElectric: do you have Postgresql 9.4?

[22:59:53] <iElectric> 9.2

[23:00:00] <iElectric> I can install 9.4

[23:00:09] <iElectric> is that the issue?

[23:00:56] <iElectric> dstufft: ^^

[23:01:44] <dstufft> iElectric: might be the issue, it works for me and I have 9.4 installed (and 9.4 is on Travis too), I never tried it on 9.2 so I don't know for sure. I know I had to do something (which is escaping me atm) to add 9.4 support to dbfixtures

[23:02:20] <iElectric> hmm

[23:03:15] <iElectric> yeah that was it

[23:03:26] <iElectric> 9.4 worked

[23:04:22] <dstufft> awesome, sorry I didn't see things earlier

[23:06:10] <iElectric> np

[23:06:18] <iElectric> I'll try to write those tests in next days

[23:06:36] <dstufft> iElectric: a quick review of the branch and it looks good to me sans the failures and missing tests

[23:06:46] <iElectric> yay!

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Thursday the 16th of April, 2015