pmxbot IRC Log Viewer

[00:00:24] <ionelmc> jck: you tell me http://blog.ionelmc.ro/2014/06/25/python-packaging-pitfalls/

[00:26:03] <jck> ionelmc: so.. there is no right answer?

[00:29:52] <ionelmc> jck: are you looking for best practices?

[00:30:09] <jck> ionelmc: yup

[00:43:01] <ionelmc> jck: i have written in the past about the layout and testing part http://blog.ionelmc.ro/2014/05/25/python-packaging/

[00:45:09] <jck> ionelmc: have you written about data_files vs package_data?

[00:45:59] <jck> basically, i want the folder(which is currently outside the package dir) to be distributed so that after a pip install, it will be programatically accessible be the user/other packages

[00:46:03] <ionelmc> jck: you should not use them at all, you duplicate filesystem information

[00:46:13] <ionelmc> then again, you layout is not simple

[00:46:26] <ionelmc> and i don't know your requirements

[00:48:09] <ionelmc> jck: distributing them as data files seems the obious choice, just put the files inside a python package (dir with __init__.py file)

[00:49:13] <ionelmc> use grafts in the manifest, don't make every file extension explicit or you gonna have a bad time

[00:49:29] <ionelmc> https://docs.python.org/2/distutils/sourcedist.html?highlight=graft#commands

[00:50:48] <jck> so, it would be package_data if i understand correctly?

[00:51:13] <ionelmc> jck: no

[00:51:17] <ionelmc> don't use that

[00:51:25] <jck> also, it would show up in a folder called 'cosimulation'(dir name) and be away from the 'myhdl'(pkg name) directory right?

[00:51:33] <ionelmc> use MANIFEST.in and include_package_data=True

[00:52:27] <ionelmc> if you can have the input file layout be the same as the output one then you can simplify alot (by not having to use data_files and package_data)

[00:53:45] <ionelmc> jck: here's my usual boilerplate: https://github.com/ionelmc/python-nameless/blob/master/setup.py#L71-L74

[00:54:02] <jck> that's reasonable, but it would include moving this folder inside the python package.

[00:54:16] <ionelmc> jck: yup, what's hard about that?

[00:54:49] <jck> ionelmc: it's not hard, it just 'feels' like these files don't belong in the package

[00:56:00] <ionelmc> jck: i'm confused, you said you want to have them available to the installed code right?

[00:56:14] <ionelmc> so the code (the package) owns them

[00:56:57] <ionelmc> i don't really understand what they do, perhaps you could explain that, and how they are related

[00:56:59] <jck> ionelmc: I want them available to the users who install this package, not to the package itself. but i see your point about simplification

[00:57:49] <jck> ionelmc: basically, if users compile these modules(with external programs), they can use additional myhdl features

[00:59:12] <ionelmc> jck: what OS are you targeting?

[00:59:36] <jck> primarily linux, maybe osx too in some cases

[01:00:41] <ionelmc> jck: any linux?

[01:00:49] <jck> ionelmc: yes

[01:01:34] <ionelmc> jck: ok, my opinion is you should distribute the addons as what they are, addons

[01:01:41] <ionelmc> make separate packages for them

[01:02:23] <ionelmc> and they would compile whatever necessary on install

[01:02:38] <ionelmc> that way you get your users use the standard tools for installing

[08:10:00] <pjdelport> ionelmc: Maybe it's worth mentioning that an alternative to MANIFEST.in is using one of the setuptools VCS plugins.

[08:10:11] <pjdelport> Like hgtools for Mercurial.

[11:48:03] <ronny> pjdelport:

[11:48:17] <ronny> pjdelport: setuptools_scm ! :)

[12:33:18] <pjdelport> ronny: Oh, neat.

[12:33:35] <pjdelport> Thanks for pointing that out. :)

[12:46:06] <ronny> its a bit self-serving :P

[12:48:56] <pjdelport> ronny: Hmm, reading through that, i think i prefer the hgtools calculates the version.

[12:49:59] <pjdelport> Specifically that you can tag things, without a trailing .0, and specify the project's default increment in your setup.py

[12:51:00] <ronny> pjdelport: well, atm there is no explici semver support, so the easiest way is the tailing .0

[12:51:18] <ronny> pjdelport: thats one of the next things i want to tackle tho

[12:51:31] <pjdelport> Have you looked at how hgtools does it?

[12:51:38] <ronny> pjdelport: one of the problems is that pep440 is way more rich than semver

[12:52:00] <ronny> (release tags, post/dev releases and other details)

[12:52:08] <ronny> pjdelport: roughly only

[12:52:24] <pjdelport> You basically just pass it increment='0.1', for example, to increment the second component. The default is 0.0.1

[12:52:48] <pjdelport> What does setuptools_scm do if there are no tags yet?

[12:52:59] <ronny> 0.1.devX

[12:53:03] <pjdelport> hgtools will use the above to generate 0.0.1dev0 by default.

[12:53:05] <pjdelport> Ah, okay.

[12:53:39] <ronny> pjdelport: that scheme prevents release tags, its only sensible if semver is enforced

[12:54:06] <ronny> (pep440 tags such as alpha, beta, release candidate)

[12:55:47] <ronny> pjdelport: in the current implementation i consiered it more important to support the more rich python version specifications than to be more easy on semver

[12:56:49] <ronny> (if you tag 1.0.0a1, a following dev version will be 1.0.0a2.devX

[12:57:18] <ronny> hten if you tag 1.0.0b1.dev, the next dev version will be 1.0.0b1.devX

[12:59:21] <ionelmc> ronny: what do you mean setuptools-scm doesn't support semver?

[12:59:57] <ronny> ionelmc: you can use semver tags just fine, but to get the increment working in a matchign way, you need to tag with a tailing .0

[13:00:44] <ronny> ionelmc: python supports a wide range of more rich versions so if i make semver specific support i break the other stuff

[13:01:01] <ronny> it will be a opt in in one of the next versions, and a bit later a opt out

[13:06:27] <ionelmc> ronny: can you make some examples with what will be different?

[13:06:58] <ronny> a tag of 0.1 will increment to 0.2.dev, if you want a 0.1.1.dev you need to tag 0.1.0

[13:08:46] <ionelmc> and with the semver support you'll be able to use 0.1 ?

[13:09:14] <ronny> yes

[13:09:28] <ionelmc> is there a way to control what kind of "upgrade" is the next version (like major or patch) ?

[13:09:50] <ronny> tag 0.2.0.dev to tag a major update

[13:11:58] <ionelmc> ronny: what happens if i still have the version field in the setup() call?

[13:12:31] <ronny> ionelmc: if you have use_scm_version thats truthy, setuptools_scm will override the version

[13:12:55] <ronny> ionelmc: bbl, lending my laptop for a lightning talk on the pythonbarcamp in cologne

[16:31:45] <apollo13> dstufft: can I tell pip to __only__ install wheels?

[16:37:57] <ionelmc> ronny: how does _scm work with sdist?

[16:38:07] <ionelmc> does it add some special file with the version inside?

[16:52:36] <ronny> ionelmc: PKG-INFO is registred as scm :P

[16:58:41] <ionelmc> ronny: so it reads up the PKG-INFO if no git/hg available yes?

[16:58:48] <ronny> yes

[16:58:53] <ronny> also .hg_archival

[16:59:10] <ionelmc> ronny: does it have anything for managing versions/tags? like "bumpversion"

[16:59:10] <ronny> however git adds no metadata files, its idiotic as usual ^^

[16:59:56] <ionelmc> ronny: what's your release process btw?

[17:00:00] <ronny> ionelmc: i have no command to add the next version/tag, cant do that saney scm agnostic and following potential security conventions

[17:00:29] <ronny> ionelmc: hg rag followed by sdist bdist_wheel upload (usually set up as a tupload tox env)

[17:00:32] <ronny> *tag

[17:00:46] <ionelmc> ronny: how does https://github.com/peritus/bumpversion do it then ?:)

[17:03:08] <Knyght> apparently this is the place to ask. I'm using zsh and virtualenvwrapper but I'm not getting any tab completion for workon and I'm not sure why

[17:03:54] <ronny> ionelmc: half-assed

[17:04:56] <ionelmc> ronny: what exactly is?

[17:06:37] <ronny> it does only normal tags, is unaware of signed tags

[17:07:20] <ronny> both hg and git have variosu ways to do signed tags, its problematic to propperly suppport those

[17:11:42] <ionelmc> ronny: oook ... anything else?

[17:11:59] <ronny> ionelmc: nothing i directly see

[17:12:44] <ronny> ionelmc: also it no longer feels necessaty to have a tool do the metadata management, the users can do exactly what they like

[17:12:53] <ionelmc> ronny: so how come you didn't get pytest to use setuptools_scm?

[17:14:55] <ronny> ionelmc: holger is not a fan of setup_requires (for obvious reasons, also he already has a process in place he likes, just forcing my approach on him directly is wrong, and the argumentative approach takes the time it takes

[17:16:12] <ionelmc> ronny: does pytest have any release automation?

[17:16:49] <ronny> less than we'd like, holger is working together with florian on the necessary details in tox/devpi, then we will take a look at the actual release process

[17:17:00] <ronny> there is a rough timeline for things to change

[17:20:25] <ionelmc> ronny: was there some page with tox/pytest release process?

[17:21:00] <ronny> i dont think so

[17:23:40] <ionelmc> ronny: found it , https://bitbucket.org/pytest-dev/pytest/src/tip/doc/en/release.txt

[17:24:32] <ionelmc> lots of manual stuff :|

[17:24:45] <ionelmc> ronny: what do you think about zest.releaser?

[17:25:37] <ronny> does too much

[17:26:05] <ronny> sometime after gumby elf i'll look at making a changelog linter/tag manager

[17:27:10] <ionelmc> ronny: well do it already, you don't want me to use flit do you ;)

[17:27:41] <ronny> hmm, well if you use flit its entirely your own fault, you wont need me to judge yourself

[17:29:37] <ionelmc> hahah harsh

[17:30:21] <ronny> :)

Log file Viewer

Help | Karma | Search:

#pypa logs for Sunday the 29th of March, 2015