pmxbot IRC Log Viewer

[00:24:19] <jhardin> Is there a way to have easy_install require a submodule?

[00:46:09] <_habnabit> jhardin, what's a submodule

[01:37:56] <jhardin> Meant subpackag

[01:40:41] <_habnabit> jhardin, then i'm not sure what you mean by 'require' a subpackage

[01:40:56] <_habnabit> jhardin, you mean as part of install_requires? that's pypi names, not package or subpackage names

[01:51:13] <jhardin> okay thanks.

[04:16:43] <blag> Is there a better place to ask questions about PyPI?

[04:26:37] <hawkowl> hi! pip isn't using some of my wheels

[04:27:29] <hawkowl> if I go `pip wheel twisted`, and then `pip install twisted`, it doesn't use the wheel

[04:27:39] <hawkowl> but it did work for some other things

[04:27:52] <hawkowl> the common thing seems to be C/CFFI extensions?

[04:32:56] <hawkowl> if I manually use -f ~/wheelhouse/ it works though.

[04:33:12] <hawkowl> I may have some wacky configuration going on here from pre-pip6 :C

[04:36:46] <hawkowl> oh, so, it automatically configures the cache... but doesn't automatically look in the wheelhouse. i think.

[04:37:20] <hawkowl> oh. pip wheel changed. hm.

[05:19:22] <blag> Is there a process for reporting a dead upstream with updated forks so PyPI can switch over to using it?

[06:29:19] <ronny> jaraco: ping?

[06:34:36] <ronny> hmm

[07:27:18] <ronny> jaraco: nm, solved all issues

[13:01:24] <nanonyme> Hmm, how do I set the default PyPI server to upload to in pypirc?

[13:02:44] <nanonyme> I'm trying to set the default to be a no-op section so I don't accidentally push anything. Instead I'm seeing an 401 from real PyPI

[13:05:43] <nanonyme> Oaaagh, so this is a stdlib botchup in distutil then that you can't actually change the default?

[13:07:45] <nanonyme> Yeah, looks like I'm right

[13:07:58] <nanonyme> Any hope of getting distutils fixed and release 2.7.10? :P

[13:13:04] <nanonyme> (or put the uploading to setuptools so it's properly upgradable)

[13:13:48] <Wooble> yeah, the latter is much more likely to actually happen :).

[13:14:57] <Wooble> although with twine exisiting no idea if adding upload to setuptools is something that would even be considered...

[13:15:32] <nanonyme> Actually yeah, putting *everything* from distutils into setuptools instead (compiling, pypi handling etc) sounds sounds somewhat nice considering ensurepip pokes setuptools in

[13:16:03] <nanonyme> The only benefit of anything being in distutils is it gets out of date and bitrots

[13:16:38] <nanonyme> But yeah, I think I found the relevant sections of distutils that are simply just plain wrong

[13:17:27] <nanonyme> If -r is missing, URL defaults to https://pypi.python.org/pypi. At that point even if you defined index-servers as something else than pypi, it gets ignored

[13:19:09] <nanonyme> So basically the default behaviour is completely broken for anyone primarily working in a corporate environment where you must not accidentally push something to real PyPI

[13:20:09] <nanonyme> (but only by specifically meaning to)

[13:24:49] <nanonyme> https://docs.python.org/2/distutils/packageindex.html#pypirc looks like password handling also works against documentation. If password is omitted, it is *not* asked but instead you get a 401 error from the server

[13:25:00] <ronny> nanonyme: i made a rule of never ever invoking register/upload myself, i use devpi, and the real uploads happen in makefiles

[13:25:32] <ronny> nanonyme: and as a extra i use hgdistver, which in the default setup adds local versions to all but tags (and those versions can never be on pypi)

[13:25:37] <ronny> hmm

[13:25:46] <ronny> oh s/hgdistver/setuptools_scm/

[13:25:53] <nanonyme> Yeah, we have devpi too

[13:25:59] <ronny> hmm, finger memory from the last 5 years is strong :P

[13:26:34] <ronny> nanonyme: so basically with something like setuptools_scm all commits get version numbers, and only tagged commits get version numbers uploadable to pypi

[13:26:42] <nanonyme> It would just be nice to get a setup with which you couldn't accidentally push any trade secrets to http://pypi.python.org/pypi. Maybe I should block http://pypi.python.org/pypi with a firewall

[13:28:04] <ronny> there is a rcfile i think

[13:28:24] <ronny> nanonyme: btw, why not standardize to devpi upload ?

[13:28:33] <Ivo> nanonyme: people do that with CVS' all the time

[13:28:43] <Ivo> I can't think of any general solution to that

[13:28:46] <nanonyme> ronny, I need to upload to both devpi and normal pyPI

[13:29:12] <nanonyme> Ivo, it'd just be nice that .pypirc made even the slightest of sense and worked as documented

[13:29:27] <Ivo> its worked for me

[13:29:42] <nanonyme> Ivo, it's impossible to change the default and password is never asked if omitted

[13:29:55] <nanonyme> The second is blatantly against Python 2 documentation

[13:30:19] <Ivo> chuck an issue on setuptools?

[13:30:31] <nanonyme> It's an issue in distutils, not setuptools

[13:30:44] <nanonyme> You need a new Python release to fix it

[13:31:09] <ronny> nanonyme: do you use setuptools or distutils directly for your setup.py?

[13:31:44] <nanonyme> ronny, I'm using setuptools in setup.py but calling python setup.py sdist upload invokes distutils, not setuptools

[13:32:01] <ronny> nanonyme: setuptools extends all commands of distutils in a way

[13:32:18] <ronny> nanonyme: so if you use setuptools.setup it could be fixed in setuptools

[13:32:29] <Ivo> nanonyme: or use twine

[13:32:33] <nanonyme> ronny, there's nothing about setuptools in the stacktrace

[13:32:34] <Ivo> it will ask you for password

[13:33:08] <ronny> hmm, reminds me, i need to look into twine, need to teach it folders and ssh

[13:33:36] <nanonyme> The top frame is setuptools invoking distutils.core.setup

[13:34:01] <nanonyme> Huh, how can that even be, setuptools should be listed somehow...

[13:34:03] <Ivo> or even file on bugs.python.org

[13:34:21] <ronny> nanonyme: question is mainly what setuptools did before

[13:35:43] <nanonyme> Hrm, how so bfore?

[13:36:50] <nanonyme> I have setuptools 12.2

[13:37:17] <ronny> nanonyme: setuptools patches around in amny parts of distutils, that might cause slight unnoticable behaviour changes (setuptools has a very strange and problematic legacy)

[13:37:28] <nanonyme> Hrm

[13:37:37] <nanonyme> Maybe even platform-dependent legacy?

[13:37:38] <Ivo> hmm setuptools doesnt hardly patch register / upload atm

[13:38:18] <ronny> hmm, maybe on windows the prompt is just broken ^^

[13:39:09] <nanonyme> That sounds quite possible if it's trying to get some secure way to get input from terminal

[13:39:17] <nanonyme> There isn't really any on Windows

[13:40:07] <ronny> nanonyme: btw, howabout getting setuptools ssh upload, and removing the normal upload/user stuff

[13:40:46] <nanonyme> ronny, I think paramiko is currently broken for Windows, fix pending for release

[13:40:54] <nanonyme> I'm using a version from git

[13:40:59] <Ivo> ronny: you mean getting pypi / warehouse ssh upload

[13:41:10] <nanonyme> But sure, in theory why not

[13:42:03] <nanonyme> ronny, bonus points if you there's a way to use PuTTY for it, very large amount of Windows users handle SSH keys through it

[13:43:34] <ronny> hmm, no idea

[13:44:16] <nanonyme> PuTTY has pscp which is basically same as scp and plink which is basically similar to ssh. Both can use SSH keys from Pageant (which is the agent)

[13:46:10] <nanonyme> Does that fit into what you had in mind at all?

[13:47:43] <nanonyme> (honestly I should probably some day learn enough about PuTTY to write some bindings so you could use SSH with it through a Python API)

[13:48:16] <nanonyme> Anyway, back to trying to publish the stuff

[13:57:13] <nanonyme> There we go, one more random package wheelified https://pypi.python.org/pypi/SendKeys/0.3

[13:57:40] <nanonyme> Now for trying to get pywinauto to PyPI too...

[14:08:25] <Ivo> i looked, doesnt seem distutils asks for password

[14:08:57] <Ivo> i wanna know when mitsuhiko is gonna upload wheels now that hes even made a tool to distribute packages through them

[14:13:57] <nanonyme> Ivo, documentation claims it does. Honestly, I think it's awful such a critical piece of Python packaging is part of stdlib

[14:15:30] <Ivo> https://hg.python.org/cpython/file/7c6e3358221a/Lib/distutils/command/upload.py#l40

[14:22:47] <jaraco> !thanks ronny

[14:22:47] <pmxbot> you're doing good work, ronny!

[14:24:17] <ronny> oh :)

[14:25:05] <ronny> jaraco: can we teach that bot sweets

[14:25:21] <Ivo> you mean snacks

[14:25:23] <Ivo> !botsnack

[14:25:23] <jaraco> I'm not familiar with sweets.

[14:25:28] <ronny> oh

[14:25:31] <ronny> heh

[14:25:32] <jaraco> But pmxbot is imminently pluggable.

[14:25:41] <jaraco> But not teachable.

[14:25:51] <jaraco> (requires new code for new behavior)

[14:26:00] <jaraco> with a few subtle exceptions

[14:26:03] <jaraco> !schneier ronny

[14:26:03] <pmxbot> ronny is the guy that put Stephen Hawking in that wheelchair.

[14:26:20] <ronny> ouch

[14:26:21] <jaraco> no accounting for taste

[14:28:47] <ronny> jaraco: can we teach setuptools to use universal wheels instead of eggs when availiable?

[14:29:12] <jaraco> ronny: yes

[14:29:51] <ronny> jaraco: also a setup_requires thats pluggable would be nice

[14:29:55] <jaraco> https://bitbucket.org/pypa/setuptools/issue/78/add-support-for-wheels-to-setuptools

[14:30:53] <jaraco> ronny: do please create a ticket and describe what you mean by setup_requires that's pluggable.

[14:31:13] <jaraco> I think what you mean is a way for those dependencies to be required only under certain circumstances.

[14:31:21] <jaraco> I desire that feature too.

[14:31:32] <jaraco> The main instance where I need that is when a certain command is present.

[14:31:46] <jaraco> (and not just present, but also implied).

[14:32:59] <ronny> jaraco: basically i want to be able to run setup.py in a way where no eggs are automatically downloaded, but instead parsable errors are shown

[14:33:44] <jaraco> aah.

[14:34:01] <jaraco> There's actually a pending pull request that adds setup_requires to the metadata (egg-info)

[14:34:28] <ronny> maybe even go as far as move the egg gathering into a sepatate command

[14:34:41] <jaraco> Oh, except that you would still have to invoke it, causing the downloads.

[14:34:46] <ronny> im opposed to setup_requies in metadata

[14:34:59] <jaraco> In that case, you may want to comment on that ticket.

[14:35:25] <jaraco> The PR was accepted, but it caused problems with upgrades, so was backed out.

[14:35:29] <Ivo> I think what we should do for that is move wheel functionality out from pip, to packaging, then get setuptools to vendor that

[14:35:36] <jaraco> The issues with upgrades have been addressed, so the PR has been re-submitted.

[14:35:52] <jaraco> Setuptools does already vendor packaging.

[14:35:55] <jaraco> fwiw

[14:36:10] <ronny> hmm, imho setuptools should de-vendor

[14:36:30] <ronny> but thats long term

[14:37:14] <ronny> first there is need for a simple wheel gatherer

[14:37:41] <Ivo> jaraco: well yeah, so therefore it gets it for free

[14:38:11] <ronny> is there a easy way to add zip files to sys.path?

[14:39:16] <jaraco> ronny: yes. just .append

[14:39:48] <jaraco> or add them to a .pth file as easy-install.pth does.

[14:42:27] <ronny> jaraco: the idea i have is to make ez_setup a really small wheel file that any python with zip support can run

[14:42:44] <ronny> jaraco: and then push setup_requirement downloads into it

[14:43:20] <ronny> jaraco_: the idea i have is to make ez_setup a really small wheel file that any python with zip support can run

[14:43:45] <ronny> jaraco_: and then push setup_requirement downloads into it

[14:45:51] <jaraco_> I'm not sure what that accomplishes. The main value I get from setup_requires is that I can declare dependencies for running tests, building docs, and uploading packages that aren't relevant to the package itself... and they don't interfere with the active environment.

[14:46:10] <jaraco_> My instinct is that ez_setup isn't a good place for that.

[14:46:36] <jaraco_> But I'm open to consider it in more detail.

[14:47:01] <ronny> jaraco: as tests/docs can be extras, and setup_requires are no longer needed for wheel installs

[14:47:15] <jaraco> Other systems rely on setup_requires to hack around setuptools (e.g. pbr).

[14:56:34] <ronny> jaraco: setup_requires as is cant go away, but a more introspectable alternative can be made in some way

[14:57:09] <ronny> hmm

[14:57:26] <jaraco> yes, probably. I'm all for refactoring to separate comonents of functionality to expose less opinionated functionality.

[14:57:35] <ronny> maybe it is a better idea to just leave it as is

[14:58:25] <ronny> jaraco: a way to opt out of auto-gathering of setup requires might be nice

[14:59:42] <ronny> hmm

[14:59:44] <jaraco> ronny: why is that?

[15:00:10] <jaraco> setup_requires is a way of a package declaring that it needs more functionality to install than your environment currently supplies.

[15:00:12] <ronny> actually, skip that, with the setup_requires writer pip can take a look

[15:01:00] <ronny> jaraco: i dont want setup.py to do any network thing

[15:01:27] <ronny> i want all network interactions to be outside of setup.py

[15:01:42] <ronny> all it should ever do is take a look at .eggs

[15:02:14] <ronny> and recommend the easy_install/pip command in case some are missing

[15:03:35] <jaraco> so something like setup.py --fail-on-missing-setup_requires

[15:03:51] <ronny> yes

[15:03:58] <jaraco> or setup.py --on-missing-setup_requires=fail

[15:04:14] <jaraco> or setup.py --on-missing-setup_requires=generate_requirements_file

[15:04:33] <jaraco> Seems reasonable

[15:04:44] <jaraco> With the default being --on-missing-setup_requires=download

[15:04:45] <ronny> too much

[15:05:26] <jaraco> So one basic challenge with this approach is that setuptools relies on distutils for the setup() framework.

[15:05:39] <jaraco> Which is frozen and old and sometimes pluggable and sometimes not.

[15:06:05] <jaraco> Which leads me to an idea I've been pondering - that setuptools should vendor/require a pypi-hosted distutils.

[15:06:08] <ronny> jaraco: the logic should be a opt-out from easy_install, a sdist has the requirements files

[15:06:33] <ronny> jaraco: tbh, i think many parts of the stdlib should be turned into preinstalled wheels

[15:06:53] <ronny> (so distributions can split them out easyly and they are pip installable

[15:07:12] <ronny> the one thats the most messy to work with is distros removing the testsuite/testsupport bits

[15:07:33] <ronny> but also stuff like tk, readline, sqlite3

[15:07:59] <ronny> that are build only optionally to begin with, its all a huge mess ^^

[15:08:08] <ronny> will explain after work

[15:09:42] <ronny> jaraco: anyway, back to setup_requires, auto-download should be a feature flag, first opt out, later opt in, much later no logner supported

[15:10:30] <ronny> the task of doing downloads/verification should be pushed into easy_install/pip

[15:11:10] <doismellburning> ~/

[15:11:16] <doismellburning> sorry

[15:11:18] <doismellburning> ronny: agreed

[15:12:44] <jaraco> ronny: that sounds fine, except that you can't deprecate a feature without first providing a story for how the current use cases would be supported.

[15:13:03] <jaraco> How would you propose, for example, that the 'irc' package run its tests?

[15:13:26] <jaraco> https://github.com/jaraco/irc/blob/master/.travis.yml

[15:13:34] <jaraco> Currently, it invokes 'setup.py test'

[15:13:48] <jaraco> Ideally, whatever replaces that model should also be able to run as a single command.

[15:14:52] <jaraco> Maybe that command is just a wrapper around "easy_install `generate_reqs_from setup.py`; ./setup test"

[15:14:54] <ronny> jaraco: i see nothing wrong with a 2 command story, separating preparing the development environment and usigng it

[15:15:31] <jaraco> ronny, I do see a problem with that because (a) I don't want to repeatedly type the same things repeatedly and (b) I'd like not to ask others to do the same.

[15:15:32] <ronny> jaraco: easy-install/pip install --just-deps-of .; setup.py test

[15:16:16] <ronny> hmm, i use tox for tests, or devpi test packagename

[15:16:29] <jaraco> In that case, it would be straightforward to have another distutils command that handles the former, and then an alias that binds the dependency download and test invocation.

[15:16:36] <ronny> so surrounding tools already handle thoe workdlow better and more detailed than setup.py

[15:19:01] <jaraco> But either of those tools still require asking the developer to install those tools first.

[15:19:07] <jaraco> So there's an implicit first step.

[15:19:25] <jaraco> Travis provides those, but stdlib doesn't.

[15:19:51] <jaraco> Installing setuptools/pip is another.

[15:20:49] <jaraco> So in the irc test scenario, if one has setuptools (the minimum implied assumption), one can run the tests.

[15:20:59] <jaraco> With a three word command.

[15:21:22] <jaraco> They don't have to think about which version of pytest they may or may not need, because the library declares an appropriate version.

[15:21:45] <jaraco> They don't need pip or tox or devpi or any other pre-requisite steps.

[15:22:07] <jaraco> Just Python + setuptools.

[15:22:14] <jaraco> And, the system environment is unaffected by running the tests.

[15:22:31] <jaraco> One can check out the repo, run the tests, and delete the repo, and the system is unchanged.

[15:22:39] <jaraco> You can't say the same for the tox or devpi story.

[15:24:50] <jaraco> I believe this was the vision of setuptools from years ago... and that setuptools would be incrementally absorbed into the stdlib until even the setuptools dependency was unnecessary.

[15:25:04] <jaraco> To be clear, I'm a big supporter of tox and devpi and virtualenv and pip.

[15:26:11] <jaraco> But the story they tell about a developer use case is clumsy - because it implies altering the system environment, which may or may not require sudo, and which leaves artifacts that might conflict with the story for other packages.

[15:27:51] <doismellburning> jaraco: just to help me understand what you've said - if tox were vendored in setuptools, then the situation described would be fine?

[15:29:13] <Ivo> not really

[15:29:25] <Ivo> the average user story isnt that they have multiple pythons installed for testing

[15:29:52] <jaraco> doismellburning, I don't think so, but maybe. tox pulls in pytest and virtualenv, which sets the stage for a model where tox could handle the complete story.

[15:29:59] <doismellburning> Ivo: I'm not sure how that relates to what I said

[15:30:13] <Ivo> thats the major usecase for tox is it not

[15:31:03] <doismellburning> jaraco: I may have been overly focussing on the "other pre-requisite steps" part of what you said

[15:31:42] <jaraco> tox would need to support (a) running without launching into subprocesses, which is problemmatic in some cases, and (b) downloading dependencies to an isolated environment, which I believe it does. There are probably other issues, but that's plausible.

[15:31:53] <Ivo> and yeah you're not just installing tox then. in packaging it helps a lot when things dont have dependency trees to install

[15:31:59] <Ivo> otherwise you're vendoring mb's of stuff

[15:32:02] <doismellburning> jaraco: ah, wasn't aware that (a) was an issue

[15:32:41] <jaraco> It's not an issue I care to raise.

[15:33:02] <Ivo> *in bootstrap part of packaging

[15:33:06] <jaraco> But it would be raised if it were the default, sanctioned way to run Python package tests.

[15:33:15] <doismellburning> jaraco: nodnod

[15:37:36] <ronny> jaraco: there should be a system integrator story for python package tests

[15:37:52] <ronny> jaraco: but that story should be different anyway

[15:38:25] <ronny> because system integrators should be going for universal wheel isntalls whenever possible and can handle extra deps for test commands easyly

[15:38:59] <ronny> and for the developer that cant run 1-2 command to set up a dev env, i have no empathy

[15:45:40] <Ivo> there is a hell of a lot to be said for making it easy for people to be able to test their changes

[15:46:00] <Ivo> ends up with a lot less useless drive-by PRs

[15:46:34] <ronny> Ivo: they need to be in a position where it it very easy to set up a development environment for the package where they can run tests

[15:46:52] <ronny> Ivo: setup.py test by no means leaves one with something like that

[15:57:04] <jaraco> ronny: how is that not the case? That's exactly the use case I strive for with the packages I maintain, even complex ones like pmxbot, which depend on MongoDB instances and network infrastructure (but gracefully degrade when they're not available).

[15:58:00] <jaraco> You can right now, check out https://bitbucket.org/yougov/pmxbot and run "python3.4 setup.py pytest" and I'm 90% confident the tests will run (probably with many skips).

[15:58:15] <ronny> jaraco: setup.py test leaves me not with a debuggable environment i can use for in detail development, all it does is pull some eggs around and run the tests

[15:58:26] <jaraco> aah

[15:58:41] <ronny> which means its perfect to run the tests, it utterly sucks for development if something broke and you want to go develop

[15:59:07] <jaraco> good point. That is a deficiency. And the transition from quickly running tests to getting into a more involved development environment is not a good one.

[16:00:35] <ronny> my oppinion is to scrap the testing toy and give people a fully featued story for going into development, ci and deployment

[16:01:40] <jaraco> I disagree. Instead provide a story that supports an easy and natural elevation from the testing story to more involved development.

[16:01:42] <ronny> stuff like check out on a linux box, upload a sdist to a devpi on every change so a poller in a windows vm in a cloud can run tests

[16:02:26] <ronny> also setup.py test doesnt support powerfull runners in any meaningfull way

[16:03:07] <jaraco> that's wrong

[16:03:25] <nanonyme> Is there any way to convince wheel that something is a binary wheel even though setup.py lists no extensions?

[16:03:36] <jaraco> I use setup.py test almost exclusively. It supports the full feature set of pytest plus supports dependency resolution.

[16:04:14] <ronny> jaraco: it completely criples the cli and use of additional self installed pytest plugins

[16:04:17] <jaraco> It does only support only one Python at a time, but otherwise, it supports rich and powerful test runs, including pdb interaction, fixture setup and teardown, etc.

[16:05:14] <jaraco> ronny, In what way does it cripple the cli? It invokes pytest the same way as the 'py.test' entry point does.

[16:05:35] <jaraco> It does require cli options be embedded in the --addopts parameter, which is less than ideal.

[16:05:38] <jaraco> But still fully functional.

[16:05:39] <ronny> jaraco: py.test plugins can add new options

[16:06:12] <ronny> jaraco: and py.test plugins not part of the setup.py test call can only be used if one messes with the surrounding environment anyway

[16:06:14] <jaraco> ronny: if pytest plugins are specified as part of the tests_require, wouldn't those options be available?

[16:06:20] <Ivo> nanonyme: say universal = False

[16:06:37] <Ivo> and/or give it a binary tag saying what it works on

[16:08:32] <ronny> jaraco: the basic problem is that wrapping around py.test the way setup.py test does takes away certain kinds of flexibility, at least your runner is reasonably doing, but still, not quite as nice as the original is (i grew a bit oppiniated on that over the years)

[16:10:51] <ronny> hmm, bit it reminds me i still need to document the the setuptools integration you made as the good integration practice

[16:11:08] <Ivo> ronny: I find for a lot of things I don't need to set up a massive dev environment for it and get everything perfect; just find where something is breaking in the code (python being interpreted is great for that), change it, then test. Simple. Makes making a good PR 5 minutes instead of 1/2 hr

[16:11:43] <jaraco> I have to gtw, but good discussino.

[16:11:46] <jaraco> *discussion

[16:11:49] <jaraco> !m

[16:11:49] <pmxbot> you're doing good work, #pypa!

[16:11:52] <Ivo> discusserino

[16:14:23] <ronny> jaraco: its issue 688 and will happen before py.test 2.7

[16:16:37] <ronny> jaraco: hmm - i just noticed that pytest-runner would also gain from wheel gathering

[17:23:02] <nanonyme> Ivo, how does the binary tag work?

[17:23:28] <nanonyme> I basically want to say this only works in 2.7

[17:24:23] <Ivo> nanonyme: http://wheel.readthedocs.org/en/latest/#defining-the-python-version

[17:25:58] <nanonyme> Hmm, that still leaves none for architecture

[17:26:37] <nanonyme> Well, none-any

[17:28:32] <nanonyme> platform-tag?

[17:29:01] <nanonyme> Apparently not

[17:30:02] <Ivo> nanonyme: plat-name

[17:31:13] <nanonyme> No impact

[17:31:39] <Ivo> nanonyme: python setup.py bdist_wheel --help

[17:32:29] <Ivo> or i believe it will be plat_name in setup.cfg

[17:32:40] <nanonyme> Yeah, it doesn't have any impact because win32 is the default. wheel changes it to any automatically

[17:33:56] <nanonyme> Doesn't look like it's possible to make it believe this package is platform-dependent

[17:34:45] <Ivo> might be something to tell wheel to allow

[17:35:45] <nanonyme> Basically what's being done here is I compiled a bunch of .pyd files manually and include them as package_data

[17:36:25] <nanonyme> Which I know is very strange but that's how this build system works

[17:40:00] <nanonyme> I guess the optimal way would be to tell setuptools that this is an extension but it's already compiled so just bundle it

[17:46:28] <Ivo> if you give it an extension wheel should think its binary

[17:46:36] <Ivo> https://bitbucket.org/pypa/wheel/src/bdf053a70200c5857c250c2044a2d91da23db4a9/wheel/bdist_wheel.py?at=default#cl-113

[17:49:25] <nanonyme> Yeah, but I don't really have any extensions as nothing to build

[17:51:23] <ronny> re

[17:53:28] <nanonyme> Anyway, this is good enough for now as I'm just going to vendor the binary wheel but I need to figure out how to convince setuptools that it's platform-dependent even with no ext_modules if I'm to publish it to our devpi server

[17:57:10] <ronny> nanonyme: you might jsut want to write a own tool that makes a zip file with dist-info and the files

[17:57:36] <ronny> nanonyme: at work we did that for a library we got from a vendor

[18:02:15] <nanonyme> ronny, I was hoping to just lie it's a normal wheel :)

[18:04:42] <nanonyme> But yeah, fair enough

[18:05:20] <nanonyme> Also I guess I could just manually rename it since it doesn't come from automation but through me

[18:08:06] <Ivo> I think there's also a file inside the .whl (zip) wheel creates which lists the tags

[18:08:55] <Ivo> but afaik pip only pays attention to the wheel's name atm

[18:10:04] <nanonyme> Right

[18:10:24] <nanonyme> Well, I'm fine with the inner stuff being looser as long as the prefiltering in file name makes non-Windows pip not download it

[18:10:45] <nanonyme> Though I guess I'm relying on simple interface being the future forever here

[18:19:06] <qwcode> looking for the logic in setuptools or distutils that determines whether a custom script is wrapped, or just copied.... ( pf_moore )

[18:19:55] <dstufft> I don't think there is any logic

[18:20:09] <dstufft> distutils's "scripts" are copied and console_script entrypoint uses wrappers

[18:21:12] <qwcode> I'm seeing a custom script get wrapped as well

[18:21:23] <qwcode> not using console_scripts

[18:21:32] <qwcode> it's just bash

[18:21:48] <qwcode> using scripts=[]

[18:23:25] <nanonyme> https://bitbucket.org/pypa/wheel/pull-request/48/added-an-option-to-build-pyc-only-wheel/diff I hope you guys at least make this result in a non-pure wheel

[18:23:51] <nanonyme> If you can't recompile .py->.pyc, I doubt it will be excessively portable

[18:25:46] <qwcode> wrapped with # EASY-INSTALL-DEV-SCRIPT:...

[18:51:17] <qwcode> dstufft, setuptools has this "is_python" function that can report false positives for scripts. if a simple bash script python-compiles ok, it gets considered python and wrapped. https://bitbucket.org/pypa/setuptools/src/4bc93ca98bbd08347ad907478bba92647855787d/setuptools/command/easy_install.py?at=default#cl-1787

[18:52:01] <qwcode> dstufft, thinking it should look at shebang first. reorder the logic in here https://bitbucket.org/pypa/setuptools/src/4bc93ca98bbd08347ad907478bba92647855787d/setuptools/command/easy_install.py?at=default#cl-1812

[19:03:18] <qwcode> dstufft, logged it. maybe I'll PR it later. https://bitbucket.org/pypa/setuptools/issue/355

Log file Viewer

Help | Karma | Search:

#pypa logs for Thursday the 26th of February, 2015