pmxbot IRC Log Viewer

[01:02:57] <Moult> Yasumoto: fixed btw

[11:40:16] <ronny> hi

[11:40:23] <ronny> how can i do recursive scans for package data?

[11:40:28] <ronny> (setuptools)

[11:53:55] <mgedmin> uh, can you elaborate?

[11:56:17] <ronny> mgedmin: im trying to turn a django app into a wheel package, propperly adding the templates is turning into a headache

[11:56:47] <mgedmin> can you link to your git repo or at least pastebin your setup.py?

[11:57:49] <mgedmin> setup(..., include_package_data=True, ...) should be enough

[11:58:03] <ronny> bpaste.net/show/9fc3f935cc85

[11:58:19] <mgedmin> but it's also a good idea to make sure your MANIFEST.in has a 'recursive-include yourpackage *.html' etc

[11:58:22] <ronny> mgedmin: i tried that before, didnt quite work, then i started to list them manually

[11:58:33] <apollo13> ronny: you can look at github.com/django/django/blob/master/MANIFEST.in and github.com/django/django/blob/master/setup.py

[11:58:46] <ronny> so i should combine manifest and include_package_data ?

[11:58:57] <mgedmin> yes

[11:59:13] <mgedmin> MANIFEST.in is optional if and only if you have the setuptools_hg plugin installed

[11:59:16] <dstufft> I've done this previously too github.com/pypa/warehouse/blob/master/setup.py#L62-L68

[11:59:30] <mgedmin> and it's easy to forget to have that and get PAIN PAIN PAIN which is why I always recommend having a complete MANIFEST.in

[11:59:52] <mgedmin> and when people complain that maintaining a MANIFEST.in by hand is tedious, I point them to pypi.python.org/pypi/check-manifest

[12:00:07] <ionelmc> it is tendious

[12:00:16] <ionelmc> cause recursive-include is tendious

[12:00:27] <ionelmc> grafts are most always maintenance-free

[12:00:55] <ronny> does it work if i have setup_requires for setuptools_hg?

[12:01:50] <mgedmin> you could try

[12:02:15] <apollo13> dstufft: migrations are package data? interesting :)

[12:04:34] <dstufft> there's no __init__.py in the versions directory so yea

[12:05:04] <doismellburning> oh crap

[12:05:18] <doismellburning> (thanks)

[12:05:36] <ronny> hmm

[12:06:21] <ronny> hmm, i need to check why hgdistver faisl to find pacakge data, i recall having a finder implemented, i suppose the tests are bad

[12:07:11] <ionelmc> ronny: why don't you use include_package_data ? you want data files outside your packages?

[12:08:09] <mgedmin> line 7 of ronny's paste: "include_package_data=True," ;)

[12:08:46] <ionelmc> mgedmin: isn't that useless if he specifies package_data manually?

[12:09:12] <mgedmin> oh, is it? I didn't know that!

[12:09:13] <ronny> it works with setuptools_hg

[12:09:33] <ionelmc> mgedmin: i'm just asking

[12:09:47] <ionelmc> not sure what are the precedence/override rules

[12:13:35] <ronny> hmm, now - is there any lib that takes requirements{,-extra-name}.txt files and puts them into install_requires and extras_require?

[12:14:22] <mgedmin> I wouldn't do that

[12:14:40] <mgedmin> I would do the opposite: have requirements.txt reuse install_requires with '-e .'

[12:15:40] <mgedmin> but if you wish, 'install_requires=open('requirements.txt').read.splitlines()' ought to work

[12:16:02] <mgedmin> (if you don't mind ResourceWarnings on Python 3.x because you're not closing the file explicitly)

[12:16:10] <doismellburning> except for the things in requirements.txt that aren't allowed in install_requires...

[12:16:42] <mgedmin> a simple matter of programming, surely :)

[12:17:14] <ionelmc> so it looks like when incl_package_data=True the files from the manifest are extended with the patterns from package_data: bitbucket.org/pypa/setuptools/src/9db269094f1dd2b79591bdfd95f1e759b647acda/setuptools/command/build_py.py?at=default#cl-91

[12:17:46] <mgedmin> in my worldview the purpose of requirements.txt and install_requires is subtly different: the 1st is for people working on your project (i.e. developers); the second is for people installing your project

[12:17:59] <ronny> btw, whats the current way of coice for having different dependencies on python2 and python3 ?

[12:18:27] <ionelmc> there are platofmr conditionals that you can shove into the extras

[12:19:15] <ionelmc> sorry

[12:19:19] <ionelmc> "environment markers"

[12:19:44] <ionelmc> python.org/dev/peps/pep-0426/#environment-markers

[12:20:02] <ionelmc> where's the doc about the extras thing?

[12:20:41] <ronny> so how is it used in setup.py?

[12:21:20] <mgedmin> and which versions of pip/setuptools support those?

[12:21:26] <ionelmc> wheel.readthedocs.org/en/latest/#defining-conditional-dependencies

[12:21:41] <ionelmc> ok, it's only for the wheels

[12:22:13] <xafer> nope, it also works with sdist

[12:22:26] <ionelmc> ronny: if you don't distribute wheels or eggs then your setup.py is always gonna be called, so you can just do the checks there (if sys.version blabla)

[12:22:28] <xafer> (and pip >=6)

[12:22:46] <ionelmc> interesting

[12:24:21] <ionelmc> i'll be honest here, i currently vendor condtional deps like argparse

[12:25:00] <mgedmin> when will python 2.6 finally die?

[12:25:03] <doismellburning> mgedmin: same; yet to experience pain fortunately

[12:25:18] <doismellburning> mgedmin: you're part of the problem :P

[12:25:37] <ionelmc> as in, he is in a big problem :-)

[12:26:06] <ionelmc> mgedmin: run away, while you still can :-P

[12:26:27] <mgedmin> ubuntu 10.04 lts on those servers is perhaps a bigger problem (LTS support expires in 2 months)

[12:26:41] <ionelmc> eh, well

[12:26:42] <mgedmin> so, the pain I experienced was rather esoteric: lists.idyll.org/pipermail/testing-in-python/2014-December/006245.html

[12:27:16] <ionelmc> it's kinda ridiculous we're talking about 2.6 whereas we should be taking about 3.x porting

[12:28:13] <ionelmc> also, latest tox doesn't work on 2.6 does it?

[12:29:36] <mgedmin> it does

[12:29:43] <mgedmin> last I checked

[12:31:10] <xafer> environment markers and extras_require should work in 2.6 with pip6

[12:32:03] <mgedmin> what about easy_install (i.e. zc.buildout)?

[12:33:21] <xafer> no idea

[12:33:58] <dstufft> they work in setuptools

[12:34:04] <dstufft> not sure what version introduced them offhand

[12:34:12] <dstufft> mgedmin: 10.04 O.O

[12:34:28] <mgedmin> :)

[12:34:46] <dstufft> my condolences

[12:35:11] <mgedmin> at least it's not RHEL

[12:35:16] <dstufft> I start getting twitchy about half way between the latest LTS release and the next LTS release

[12:37:35] <ronny> ionelmc: i'll have wheel only deployments

[12:38:36] <ionelmc> you should write RHELL from now on

[12:39:23] <ronny> so it should be fine if i have a setup_requires with hte right setuptools version?

[12:39:50] <ronny> hmm, im a bit thorn between setup.py and requirements.txt

[12:39:59] <ionelmc> setup_requires wouldn't be used for installing wheels

[12:40:08] <ionelmc> s/for/when/

[12:42:03] <ronny> ionelmc: im packaging an app thats to be deployed as wheel

[12:42:11] <ronny> currently we have requirements.txt there

[12:47:52] <ionelmc> what sort of app can be installed via just a wheel

[12:48:20] <ronny> ionelmc: django apps pretty much only need configuration and django-admin

[12:48:24] <ionelmc> apps usually have services that need specific actions (restarts, migrations etc) when stuff is upgraded

[12:48:38] <ionelmc> s/stuff/code/

[12:48:48] <ronny> and having everything as wheel makes deploy to neww virtualenv insanely easy

[12:49:11] <ionelmc> ah, so then you have install scripts

[12:51:16] <ronny> ionelmc: im creating a deploy utility, will take an app, and put it on appservers, run migrations, restart standard services

[12:53:36] <doismellburning> do y'all have any strong opinions on dependency_links?

[12:53:50] <mgedmin> avoid

[12:54:08] <doismellburning> (specifically for having project A branch X depend on project B branch Y during development)

[12:54:16] <doismellburning> (and never ever having them on mainline)

[12:55:23] <mgedmin> I would indicate in setup

[12:55:24] <ronny> btw, is there any common practice for turning git versions of other projects into pip dependencies that are normally installable from a index?

[12:55:32] <doismellburning> mgedmin: "indicate in setup"?

[12:55:45] <mgedmin> (in install_requires) that I need project B version >= something

[12:56:13] <mgedmin> and then in project A's requirements.txt I'd do something to explain where to find that version of project B

[12:56:25] <mgedmin> maybe with a github link that points to a branch/commit

[12:56:45] <mgedmin> maybe with -f intranet.example.com/dependencies

[12:56:48] <doismellburning> ngh requirements.txt

[12:57:10] <mgedmin> not necessarily requirements.txt; buildout.cfg is another option :)

[12:57:37] <doismellburning> ...what on earth is that?

[12:58:08] <mgedmin> if you don't use buildout already, you probably don't want to know

[12:58:13] <doismellburning> right

[13:04:30] <doismellburning> (context: gist.github.com/doismellburning/549c6958ee48664da789 is a rough draft of guidance I'm thinking of issuing)

[13:04:31] <ronny> dstufft: is there anything to have custom own version of 3rd party packages that dooesnt mess up (made the misstake of uploading the "next" version of something to the internal devpi - it wasnt pretty

[13:04:56] <dstufft> you can use local versions to indicate you've customized it

[13:05:16] <dstufft> if you've customized version 1.0, upload a package 1.0+ronny.1

[13:05:22] <dstufft> to your internal devpi

[13:09:34] <ronny> oh, how exactly do those work, and where is it documented?

[13:11:05] <ronny> dstufft: im just skimming the pep, is there mroe docs on using local versions

[13:11:59] <dstufft> there's not more documentation sadly, basically 1.0+ronny.1 is both ==1.0 and > 1.0 and PyPI won't allow the original author to upload local versions to PyPI

[13:12:25] <dstufft> so it's 1.0 + some some stuff that is identified by this string

[13:12:37] <dstufft> and you're promised that the original author won't release the same version on PyPI

[13:13:25] <ronny> i see

[18:44:54] <Yasumoto> wickman: nudge on github.com/pantsbuild/pex/pull/33/files :D

[18:45:11] <Yasumoto> (and I think github.com/pantsbuild/pex/pull/32 is good to merge, but I'm not part of pantsbuild)

[21:36:19] <xafer> hello, I was looking for some entry points documentation. Are they only defined in setuptools ? and not standardized in any pep ?

[21:40:04] <dstufft|vpn> xafer: correct

[21:44:47] <xafer> but some entrypoints can also be defined in wheels via entry_points.txt

[21:48:21] <dstufft|vpn> xafer: that's not a feature of wheels, that's just wheels passing along the setuptools metadata

[21:48:30] <dstufft|vpn> wheels will pass along any extra metadta added to the egg-info

[22:05:27] <xafer> indeed ! thanks

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 27th of January, 2015