pmxbot IRC Log Viewer

[02:20:57] <Ivo> dstufft: that's why I was asking about setting up testpypi.pypa.io, to stop relying on pypi.appspot.com

[02:27:32] <Ivo> Another random pypi would do as well though (sees PR)

[17:45:06] <ionelmc> qwcode: hey

[17:45:39] <ionelmc> i'm looking at https://github.com/pypa/python-packaging-user-guide/blame/master/source/tutorial.rst#L340-L358

[17:46:05] <ionelmc> i wonder if there should be only one way to do it

[17:46:43] <ionelmc> there are way to many options there, some confusing, some error-prone

[17:49:08] <ionelmc> s/to/too/

[17:54:50] <qwcode> ionelmc, confusing? as for error prone, I tried to cover the gotchas on certain techniques. I wasn't sure about declaring the single solution for everybody, and if I did, people would constantly raise the other alternatives as possibilities, so I felt the need to cover all the solutions that might work for people.

[17:55:30] <ionelmc> qwcode: i don't mean to remove em

[17:56:08] <ionelmc> just reorganize them in a way that there's only one recommended way (and explanations of why)

[17:56:12] <qwcode> you want to declare a winner for most? I can see that

[17:56:35] <ionelmc> qwcode: in the idea that less is more

[17:56:36] <ionelmc> yes

[17:57:01] <ionelmc> now the question remains, which solution is least evil

[17:57:19] <qwcode> I'm certanly open to a PR that declares a winner with good arguments. I honestly just wasn't that confident about doing that, but atleast wanted to lay out the solutions, and frankly was pretty burnt out on that fiddlestick topic

[17:57:33] <qwcode> : )

[17:57:47] <ionelmc> i'd vote for the exec, having seen how the other could fail

[17:58:02] <ionelmc> i'd like to discuss before doing any work

[17:58:10] <ionelmc> i hate having a pr rejected :P

[17:59:00] <ionelmc> for #1: brittle parsing, could start failing if someone starts adding stuff without knowing what's in setup.py

[17:59:44] <ionelmc> for #2: pretty robust, assuming you're always using a separate version.py file

[18:00:08] <qwcode> Ivo might have an opinion on a winner

[18:00:17] <Ivo> what what

[18:00:38] <Ivo> oh god, yeah

[18:00:43] <Ivo> there should be one way to do thihngs

[18:00:44] <Ivo> not 7

[18:00:49] <qwcode> regarding the version section in the PUG offering too many solutions, but no winner

[18:00:53] <ionelmc> for #3: regex could fail later, eg: someone changes from single to double quotes or thinks it's a great idea to create the string with % or .format()

[18:00:53] <Ivo> or 6

[18:01:28] <ionelmc> for #4: pkg_resources not available, package not properly installed, all sorts of unpredictable failures

[18:02:18] <ionelmc> for #5: additional unreliable process, someone forgets to bump versoin in both files - now you have a release on pypi with 2 versions

[18:03:05] <ionelmc> for #6: people always import stuff in __init__.py. always. you can't tell them not to.

[18:03:14] <ionelmc> it's just to convenient

[18:03:20] <ionelmc> :)

[18:03:21] <ionelmc> now

[18:03:29] <ionelmc> which of those is worst ?

[18:03:47] <Ivo> #6 isnt telling them not to, its telling them what happens when they do

[18:04:23] <ionelmc> if you give people guns bullets you'll have bulletholes

[18:04:32] <ionelmc> s/bullets//

[18:04:54] <ionelmc> i think #6 is bad cause it requires too much discipline

[18:05:31] <ionelmc> what's your take on #3 ?

[18:07:39] <Ivo> i look at this from in the utopian future perspective; my opinion of that is that metadata should be in a static file, readable by anything, because its a static file, and not a crazy dynamic setup() function which only setuptools dare execute to extract values; so the recommendation should move towards that utopia

[18:09:49] <ionelmc> lvo: setup.cfg !

[18:09:55] <Ivo> i.e something like https://bitbucket.org/dhellmann/virtualenvwrapper/src/58c2459e5b27e3876b99842f323222349d1b6ed1/setup.cfg?at=master except pbr seems to do some magic to extract the version rather than include it

[18:10:05] <Ivo> setup.cfg is in a bad spot atm

[18:10:16] <Ivo> because it has two conflicting uses

[18:10:22] <Ivo> I've already seen one issue because of it

[18:10:39] <Ivo> maybe its ok for metadata

[18:10:41] <ionelmc> lvo: can you give examples?

[18:11:03] <Ivo> problem is setup.cfg if you read the docs for it is actually meant to be overridable and useable in a local build environment

[18:11:32] <ionelmc> and the actual situation is?

[18:11:34] <Ivo> i.e if you have a setup.cfg in your cwd, setuptools is supposed to use that, not the setup.cfg in the package

[18:11:38] <Ivo> thats its original use

[18:11:58] <Ivo> but now people are using it to specify static package information

[18:12:05] <ionelmc> it think that's long gone :)

[18:12:16] <Ivo> nothings too late to fix

[18:12:59] <ionelmc> btw, i'm trying to conceive a *good* package template here: https://github.com/ionelmc/cookiecutter-pylibrary

[18:13:00] <Ivo> so on one hand package is using it to specify build information that should always be there, but any random setup.cfg in a cwd can override it

[18:13:20] <ionelmc> for the version thing i have used the #5 pattern tho i'm not sure about it now

[18:13:47] <Ivo> pbr is that..

[18:14:11] <Ivo> I'd like an anologue of 1 the best

[18:15:05] <ionelmc> btw, i dumped everything i could in setup.cfg :)

[18:16:55] <Ivo> well its just peoples ignorance that has led to it having a conflicting dual purpose

[18:17:14] <Ivo> makes a good argument for getting on with an sdist 2.0...

[18:18:23] <ionelmc> lvo: so you're using pbr?

[18:18:36] <Ivo> no

[18:18:41] <Ivo> its also bad

[18:18:57] <Ivo> good intentinos

[18:19:04] <Ivo> some bad decisions

[18:19:07] <ionelmc> what's wrong with it?

[18:19:17] <Ivo> like deciding that requirements.txt and install_requires are the same thing

[18:19:20] <Ivo> and using setup.cfg

[18:21:50] <ionelmc> Ivo: mkay ... but why is that wrong?

[18:22:05] <ionelmc> ignoring setup.cfg for a moment

[18:22:15] <Ivo> https://caremad.io/blog/setup-vs-requirement/

[18:23:45] <ionelmc> Ivo: ah yes but most people don't care about concrete vs abstract ?

[18:24:15] <Ivo> most people don't know what's good for them

[18:24:28] <ionelmc> in the idea that most people don't use a different package index for dev/desting

[18:24:48] <ionelmc> so the abstract/concrete distinction serves no purpose there

[18:24:53] <ionelmc> agree? :)

[18:25:46] <Ivo> most people still use dependency links..'

[18:25:54] <Ivo> need to figure out a solution to that

[18:27:06] <ionelmc> hey

[18:27:27] <ionelmc> haven't seen a package with dependency_links in a while ...

[18:28:38] <Ivo> its probably the most complained about thing at the moment

[18:28:52] <Ivo> in aggregate

[18:29:17] <cdunklau> ionelmc: so did i miss any consensus?

[18:29:46] <ionelmc> Ivo: which one did you like again ?

[18:30:01] <Ivo> 1 is the closest to ideal

[18:30:13] <Ivo> but not particularly ideal itself

[18:30:19] <Ivo> because people will complain

[18:30:31] <cdunklau> and because mypackage.__version__

[18:30:36] <cdunklau> it's really nice to have that

[18:30:58] <Ivo> should really find out what all the other package managers do

[18:31:10] <ionelmc> what's wrong with the regex ?

[18:31:10] <Ivo> and if every other language exhibits has a pressing

[18:31:15] <cdunklau> i mean that attribute, not the import thing

[18:31:22] <ionelmc> eg: celery uses the regex

[18:31:23] <Ivo> and if every other language exhibits a pressing need to programmatically access the version

[18:34:18] <ionelmc> i have looked at the d2to1 (the setup.cfg metadata thing) and the packaging options looks mostly the same as in distutils

[18:34:21] <ionelmc> some crooked options

[18:34:49] <ionelmc> eg, package and modules are *still* handled separatelly

[18:35:49] <ionelmc> i find that rather annoying and ridiculous, distutils/setuptools/whatever not beeing about to figure out on its own if you distribute a module or a package

[18:36:07] <ionelmc> s/about/able/

[18:36:11] <Ivo> you can distribute both

[18:36:53] <ionelmc> Ivo: sure, do you like this then https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/setup.py#L29-L31 ?

[18:36:55] <Ivo> Would setuptools automatically doing find_packages() satisfy you in that regard?

[18:37:04] <ionelmc> haven't seen anyone trying to discover the modules

[18:37:27] <ionelmc> i'd like to not have to do py_modules=[splitext(basename(i))[0] for i in glob.glob("src/*.py")],

[18:37:35] <ionelmc> feels silly

[18:38:03] <ionelmc> btw, that wouldn't work without a src dir :)

[18:38:14] <ionelmc> cdunklau: ^ :)

[18:38:15] <Ivo> ionelmc: any particular reason you only ever import one thing per import line?

[18:38:17] <DanielHolth> src dirs make things easier

[18:39:05] <cdunklau> meeeeh

[18:39:22] <cdunklau> src/no src feels more like a religious argument every day

[18:39:23] <ionelmc> DanielHolth: glad someone is agreeing - might want give me some support here http://blog.ionelmc.ro/2014/05/25/python-packaging/ :p

[18:40:11] <ionelmc> cdunklau: it's not like religion, in the worst case it's like fashion

[18:41:10] <ionelmc> Ivo: because it makes an easier job to remove unused imports, eg: ide/editor highlight the lines that aren't used

[18:42:14] <ionelmc> if i had everything on one line then i'd actually have to look couple of times at the message to see which of the many imports are not used

[18:42:32] <ionelmc> flat is better than nested no? :)

[18:52:21] <cdunklau> ionelmc: regarding single-line imports, if you just run flake8 it will catch that kind of thing

[18:53:00] <cdunklau> err, pyflakes. but flake8 bundles it

[18:53:41] <ionelmc> ah yes, but i like to also sort the imports

[18:53:48] <ionelmc> so i use this nice tool isort

[18:53:52] <ionelmc> https://pypi.python.org/pypi/isort

[18:54:02] <ionelmc> eg https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/.isort.cfg

[18:55:12] <ionelmc> cdunklau: i also included flake8: https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/tox.tmpl.ini#L58-L60

[18:55:25] <ionelmc> could use some feedback, maybe i missed something

[18:56:28] <cdunklau> ionelmc: dunno

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 11th of June, 2014