Log file Viewer
#pypa logs for Thursday the 19th of February, 2015
[00:00:17] <ronny> but there usually is only one main app, and the version of that one goes to the virtualenv name
[01:01:14] <[Tritium]> welp, i should have been here an hour ago, cause that would have been a factual counterpoint in that discussion
[07:06:41] <ronny> [Tritium]: he wants it in setup.py, which is kind of fail and shuldnt be fixed as well
[13:18:01] <SamuelMarks> What's wrong with—e.g.: my setup.py—that prevents me from importing from this file? - https://github.com/bettertutors/sql-models/blob/master/bettertutors_sql_models/User.py
[14:36:11] <ionelmc> SamuelMarks: unless you want to learn packaging you'd be better off using a package template
[17:02:32] <nedbat> are there organizational logins to PyPI? edX has a number of repos, and we should start putting them up on PyPI, but we're wondering who to use as "author", etc.
[17:04:52] <dstufft> we do not have organization support, it's on a TODO list but not super high priority
[17:08:08] <ronny> im wondering if it ould be ok to pester jaraco abit about putting his comments wrt setuptools_scm into issues
[17:08:19] <nedbat> dstufft: I guess that means we should make a new account and share the password.
[17:12:12] <doismellburning> yeah that's what we do at laterpay - there's an LP account that owns *, but we give individuals PyPI access for day-to-day use
[17:12:29] <dstufft> when it detects a new tag it builds the package and uploads it with the openstackci user
[17:16:43] <dstufft> having a edX account that only 2 or 3 people have access to is useful in it's own right, makes it easy to recover a project if the other names attached to it quit and aren't available, and on warehouse there are user pages so it makes it easy to see all the edX stuff in one place
[17:32:53] <mitsuhiko> right now when i do something in python the way i approach things is that I either deal with a requirement name or the path to a folder containing a setup.py file, right?
[17:33:07] <mitsuhiko> but the end result is basically that there is a setup.py file which i work with
[17:33:17] <mitsuhiko> now obviously that file is already quite annoying because you can't really parse it
[17:33:38] <mitsuhiko> the problem is though, that this only tells me about the references to package names
[17:34:01] <mitsuhiko> in cargo i have a toml file which defines my package dependencies (similar to the way setup.py works), so that part is the same
[17:34:16] <mitsuhiko> but unlike python, the local dependencies or something of that sort, can be defined in a config file i can discover automatically
[17:34:32] <mitsuhiko> so any tool that i write can (even if a package has not been installed yet) figure out where it might come from
[17:35:37] <mitsuhiko> in python while there can be requirement files, they are only short lived for an installation process
[17:36:05] <mitsuhiko> you cannot have the base requirement in setup.py either (by name) unless you remember to run the requirement install to a local path first
[17:36:25] <mitsuhiko> i just name my depenency (which does not exist on crates.io) in my toml file and set up a local dependency in my .cargo config
[17:37:09] <dstufft> so there's no real reason we couldn't support named mappings in the pip config other than we haven't done it
[17:37:39] <mitsuhiko> dstufft: the reason it comes up for me is because people have local dependencies which are not in setup.py
[17:38:52] <dstufft> well people are generally confuseda bout the difference between requirements.txt and setup.py :/
[17:39:16] <jessamynsmith> dstufft: I was about to link an article about that, and I think it's probably you? https://caremad.io/2013/07/setup-vs-requirement/
[17:40:32] <dstufft> but yea, people do sometimes put things only in requirements.txt and not in setup.py, but it's a bit different right? cargo gets to define the entrypoint, it can ensure that you only see the stuff you've defined in your Cargo.toml file and nothing else
[17:40:55] <dstufft> so we don't have any real good way to enforce that you only get to see the stuff you've defined
[17:41:18] <dstufft> so at the end of the day there's always going to be the case where someone depends on something they didn't put into the cannonical place for dependencies (setup.py)
[17:42:00] <mitsuhiko> dstufft: i'm not surprised users get confused "pip install --editable ." cannot work
[17:43:13] <[Tritium]> Ok, really considering creating the package 'dontsudopip' which has os.unlink('/') in its setup.py
[17:44:13] <dstufft> [Tritium]: only if you also create the package "dontpipinstalluser" which has adds a fake sudo binary on the user's path which runs os.unlike("/") the next time you try to sudo
[17:46:01] <dstufft> mitsuhiko: I do agree that the way all of this works is super confusing right now, I have some plans for untangling it, and I think we'll be able to get a similar workflow to what you're doing in cargo, with the caveat that since we don't control the entry point (ala cargo build) we can't enforce that people don't require you to install something in a non standard or wierd way
[17:46:57] <[Tritium]> ok, different topic, what is the binary wheel situation on osx? I dont have a mac, but i heard that its... problamatic
[17:47:00] <mitsuhiko> i'm looking more into pex at the moment. that seems like potentially the right way forward
[17:47:35] <[Tritium]> well, there is the system vs. python.org python and sdk versions... im confused on that
[17:47:35] <dstufft> mitsuhiko: so I'm talking to a number of people about enabling a standard supported way to get a go-lang style "static" build of a python tool
[17:48:27] <dstufft> [Tritium]: it should generally work if it finds a wheel it thinks will work, other than if you link something non standard that we can't protect against unless you static link it in the wheel
[17:48:33] <mitsuhiko> dstufft: the only thing that blocks pex to become more popular is that we still have no reasonable way to reference resources that are not on the filesystem
[17:49:13] <mitsuhiko> but whatever a real compiled binary would affect, pex also affects (wrt to resources and similar things0
[17:49:17] <dstufft> mitsuhiko: further, ideally I want it to be pex + the python interpreter in one file and even more ideally limited need to unzip stuff (but that requires a culture change)
[17:49:32] <dstufft> but yes, step 1 is to make it so pex works really well and has all the tooling it needs around that
[17:51:08] <dstufft> mitsuhiko: I have an import-sig thread that I need go poke again about getting the pkg_resource like APIs added to the stdlib for manipulating resources. If you have a better idea for what the API would look like I'd be glad to see it
[17:51:41] <mitsuhiko> dstufft: pkg_resource is so bad for actually getting file streams. that needs a better api
[19:39:14] <willingc> dstufft: I've been using pyenv for the past month and it's been working out well for various versions of python and anaconda for teaching purposes :)
[19:41:52] <dstufft> I sometimes think about making something similar that works on windows too and uses precompiled binaries instead of compiling at install time
[19:43:31] <willingc> dstufft: what other favorites beyond pyenv do you have that make things easier for users?
[19:45:37] <dstufft> mktmpenv is great for "I just want to install and try this thing out but I don't want it to infect anything else"
[19:53:35] <jessamynsmith> I was so thrilled to discover I could update a package in every virtualenv
[21:35:15] <deuxpi> Hi! I'm trying to write a functional test for a setuptools extension using a subprocess; does anybody have an idea how I can 'setup_requires' my top-level package?
[21:49:52] <deuxpi> Oh looks like playing with PYTHONPATH may encourage pkg_resources to use my module