Log file Viewer

[07:39:45] <pmxbot> RonnyPfannschmidt pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[07:39:45] <pmxbot> fix makefile s/setuptools/pkg_resources/

[07:45:20] <ronny> i knew i forgor something

[07:47:42] <ronny> dstufft: im preparing a utility function in pkg_ressources, get_version_optional(dist) for use in __init__.py

[07:47:57] <dstufft> what's it do

[07:49:10] <ronny> dstufft: elevates the need to track version numbers in files, imho version should always come from metadata

[07:49:20] <dstufft> ronny: disagree!

[07:49:23] <dstufft> for a few reasons

[07:49:31] <ronny> please elaborate

[07:50:58] <dstufft> 1) that tells me what version the metadata thinks is installed, it doesn't tell me what version I've actually just imported. If I'm inside of a checkout of a project, or I've added something to the path using PYTHONPATH or any means of getting a directory onto sys.path without actually installing it, then ``import foo; foo.__version__`` is going to give me flat out wrong information

[07:51:33] <ronny> so the correct helper should always try to use the colocated dist-info?

[07:52:05] <dstufft> That might be OK, I'd have to think about it, and it should fail if there isn't one nearby

[07:52:12] <dstufft> wrong information is worse than no information

[07:52:13] <ronny> dstufft: the intent is to have a helper in pkg_resources that tells the version for the file it was called from

[07:52:51] <ronny> so in checkouts it would have no information or the one from the last dist/egg-info call, and for installs it would have the installed version

[07:53:24] <dstufft> 2) is specific to pkg_resources, but importing pkg_resources is not a lightweight import. It is *really* slow and I don't really want to pay the cost for that on every import of my package regardless of if they want the version info or not

[07:53:42] <dstufft> it also has hella sideeffects

[07:55:32] <dstufft> 3) isn't pkg_resources specific, but specific to any non stdlib metadata reading library - I don't think it's worth it to add a runtime dependency on pkg_resources (or any metadata lib) just to get version info

[07:56:27] <ronny> dstufft: hmm, then something lightweight or no info by default is better?

[07:56:58] <dstufft> (2 and 3 are very subjective so others might not agree with me, I think 1 is pretty sane and more likely to be agreed on)

[07:57:44] <ronny> yes, 1 is very sane, but 2 and 3 are indeed noteworthy

[07:58:21] <ronny> i would use it in my libraries, since they use pkg_resources anyway

[07:58:46] <dstufft> yea, if you already use pkg_resources then it's not a big deal

[07:59:56] <ronny> dstufft: for most of my projects every commit gets a own version number, i suppose i should reintroduce a version_file in setuptools_scm so people can write a mypkg.version module on egg_info time?

[08:00:19] <dstufft> I *think* the API I want, (and that other people want) is something like import foo; pkg_resources.version_for_module(foo), but that's not exactly easily achievable right now I think, since by default I don't think there's anything tying the import "foo" to a particular dist-info file

[08:01:17] <ronny> dstufft: the toplevesl.txt file?

[08:01:39] <dstufft> ronny: Hmm, I forget what's all contained in that, but it might be enough to do that

[08:02:12] <ronny> hmm, ok, so bascially 2 things needed , version modules and pkg_resources enhaned support

[08:02:46] <ronny> version modules goes to setuptools_scm, the helper goes to pkg_resources, proejcts where pkg_resources is to heavy can use version modules

[08:04:15] <dstufft> I haven't looked at setuptools_scm, but if I can write out the version information inside the installed thing in some way that I could access it, then it would be something that I'd want to look at for using in my own projects

[08:04:40] <dstufft> oh, and if it can function in a way so that you don't need setuptools_scm when installing from sdist

[08:05:37] <ronny> dstufft: currently setuptools_scm is needed from sdist, due to setultools limitations, those will get fixed eventually

[08:05:52] <dstufft> ronny: awesome!

[08:06:23] <dstufft> I really want a system that can integrate with the VCS to infer some data, but which doesn't require being installed or setup_requires'd

[08:06:45] <dstufft> but I don't have the time to actually work on such a system :( so I just manually keep data in sync

[08:07:17] <ronny> dstufft: i'm also thinking of making a release bundleing tool that will build universal wheels and dsists including a setup.py

[08:09:35] <ronny> dstufft: the idea is to remove setuptools from the release and upload process and leave it only in the install/test process for package maintainers

[08:10:11] <dstufft> ronny: if I understand correctly, that sounds like a good thing

[08:10:56] <ronny> dstufft: i already took the pypi name releasetool :P

[08:11:26] <ronny> oh, its gone ^^

[08:18:17] <ronny> dstufft: it needs a godo name first, i suspect the first implementation will be less than 300 loc (i'll promote a layout where src is used)

[08:18:22] <ronny> *good

[08:20:50] <ronny> dstufft: btw, what would be a good way to upload bundles of static files/assets to pypi? im pondering how to makr those archives

[08:21:09] <dstufft> ronny: what do you mean by "bundles of static assets", like CSS?

[08:21:28] <dstufft> make a python package that only has data files I guess

[08:22:30] <ronny> dstufft: bascialy i want to upload only the assets in some way without creating a mess

[08:22:44] <ronny> i was thinking of something like a wheel with a static tag instead of py2/py3

[08:23:26] <dstufft> I don't think we have any way of marking that, not sure we need it either, py2.py3 should be fine, since static data by defintion works for both py2 and py3 yea?

[08:27:37] <ronny> dstufft: i wanted to avoid making a complete package, just some kind of archive i can put on pypi, similr to doc uploads

[08:30:00] <ronny> hmm

[08:30:07] <ronny> i'll reiterate on it later

[08:30:35] <dstufft> i'd have to think about that, off hand I'm not sure that it's something I'd generally be OK with (allowing arbitary bundles of crapt o be uploaded is something I want to get away from tbh)

[08:32:51] <ronny> dstufft: true

[08:33:04] <ronny> hmm, ah, i have a better idea that will always work now :)

[16:33:52] <ronny> re

[16:36:33] <sigmavirus24> re.search

[16:36:42] <sigmavirus24> (c'mon everyone, let's collaboratively build a line of code!)

[16:37:34] <xafer> re.search +

[16:38:07] <sigmavirus24> damnit xafer you ruin everything =P

[16:38:58] <Wooble> re.search + magic_function_radder_thing

[16:44:11] <xafer> sorry, was too tempting, maybe you could have tried to call type to create a crazy class with __radd__ implementation ?

[16:45:56] <xafer> re.search + type('test', (object,), {'__radd__': lambda s, other: True})(), indeed :o

[16:47:35] <sigmavirus24> NEVAR

[16:47:43] <sigmavirus24> I'm not dabeaz