Log file Viewer
#pypa logs for Tuesday the 7th of October, 2014
[07:36:57] <psi29a> I have a question regarding a broken package on pypi: https://pypi.python.org/pypi/Ldaptor/0.0.53
[07:37:17] <psi29a> I'm not the maintainer, but he hasn't been reachable in months (if not years now)
[08:46:19] <vanderkerkoff> Hello there. Could someone either tell me or point me at a website that explains exactly what >= means in a requirements.txt file, and also how it translates when you have dependencies of a module?
[09:00:33] <doismellburning> vanderkerkoff: https://en.wikipedia.org/wiki/Greater-than_sign#Greater-than_sign_plus_equals_sign
[09:03:03] <vanderkerkoff> so if run pip install wagtail>=0.6, and I already have wagtail 0.6 installed, what will happen?
[09:04:38] <doismellburning> vanderkerkoff: and that will be true even if you use --upgrade, because wagtail 0.6 is latest stable
[09:05:44] <vanderkerkoff> If I know that wagtail 0.6 has a dependendent module described like this, django-modelcluster>=0.3, then if my system has 0.3, it wont upgrade it will it?
[09:07:29] <vanderkerkoff> whilst I’m here, what’s the easiest way to display dependent modules of a module?
[09:27:10] <vanderkerkoff> if I didn’t have wagtail on the system, and the latest stable version was 0.7 say, and I ran pip install wagtail>=0.6, would 0.7 install or 0.6?
[10:49:25] <straycat> Is there anyway to reliably determine the upstream repo from a package's json on pypi. I see there's a home_page attribute that tends to have a link to a repository, but is that a requirement or can the packager put whatever they want in their e.g. a link to the project's home page ?
[11:14:05] <tomprince> psi29a: <dstufft> toss an email to donald@python.org and richard@python.org with links and such and we'll take a look, most likely richard will he normally handles that kind of stuff
[11:14:53] <psi29a> Richard did... until he said: "Due to recent events there has been a change in policy and I will no longer reassign projects without the explicit authorisation of the previous owner. Sorry."
[11:17:43] <apollo13> psi29a: just because someone doesn't respond you can't easily hand over a package
[11:18:39] <psi29a> we have a release and we'de (twisted) would like to see the package properly maintained
[11:18:47] <dstufft> There was a recent discussion on distutils-sig about the transfer of project ownership.
[11:19:14] <apollo13> psi29a: no matter how broken it is you can't just transfer ownership without approvement
[11:21:12] <tomprince> apollo13: I think there is room for transfering ownership without approval. It certainly has to be a case by case basis.
[11:22:33] <psi29a> I still don't know what lead to the policy change even after asking for it... it was a very abrupt message and ticket closure for a process that supposedly was all underway
[11:23:37] <tomprince> psi29a: https://mail.python.org/pipermail/distutils-sig/2014-September/024832.html
[11:23:43] <dstufft> psi29a: Here's the more or less basic rundown, previously PyPI would have transfered this (speaking as one of two people with the ability do so), however a recent transfer has caused some backlash within the community and as a result a policy change was made. Richard made the policy change, so he's unlikely to break his own policy, and I'm not going to overrule Richard, and that leaves you with noone else with the ability to do what you want
[11:23:43] <dstufft> here. If you feel strongly about this name, I suggest you pull up the distutils-sig archive, there was a recent thread started by Daniel Greenfield about the django-registration package which is where the policy change got hashed out in, and then if you still agree that you should have that name, post your own thread arguing why the new policy is too broad.
[11:25:04] <dstufft> I'm not sure I completely agree with the new policy, as I think there *are* cases where it makes total sense to transfer a project
[11:25:42] <dstufft> but I'm not going to disregard the policy nor will I ignore what decision he's already made on this particular project
[11:26:25] <psi29a> I have no idea what has happened to Anton, I hope he is OK. However, at face value, this new policy pretty much kills the name of a package once the maintainer is no longer able to maintain it. Considering that the name of the package is exactly the name of the project itself, that is going to cause problems
[11:27:04] <dstufft> (You could optionally also avail yourself of Richard again, but I think he's unlikely to change his mind without more discussion on distutils-sig about whether or not it's appropiate to transfer a package and in which cases it's appropiate to do so)
[11:28:07] <dstufft> psi29a: The crux of the issue comes down to, who has the right to continue to maintain a project once the original maintainer is gone
[11:28:41] <psi29a> well... Anton was never the maintainer of the source code, he was just ever the package maintainer with his own fork of the project
[11:30:34] <tomprince> I suspect there are a few cases (like this one), that date to when pypi wasn't as ubiquitous, when the person who uploaded to pypi wasn't the original author (as is this case).
[11:30:45] <psi29a> the abruptness of the ticket closure and terse information didn't make my morning bright and happy haha
[11:31:06] <dstufft> there are also cases where it's pretty obvious who should get control over a project on PyPI
[11:31:49] <tomprince> It is probably reasonable to say *now*, if you didn't upload to pypi with your name, tough. But that wasn't always the case.
[11:32:13] <psi29a> so my best course of action is to go on the mailing list, with a new subject (thread) to discuss the new policy and how it effects Ldaptor?
[11:32:27] <dstufft> Like if say the four people who can upload to Django's entry on PyPI suddenly vanished (but were otherwise completely safe because hypothetical death is lame ;)) I think we could figure out who to hand the reins over too
[11:33:13] <tomprince> It is also unfortunate, that we didn't try to get the name when the project was first revived, since that was several months ago, but the project wasn't in a state to be released then.
[11:34:32] <psi29a> I also tried to get everything done on PyPI as well to point to its new home on twisted
[11:36:19] <psi29a> so my best course of action is to go on the mailing list, with a new subject (thread) to discuss the new policy and how it effects Ldaptor?
[11:36:41] <apollo13> dstufft: yes, cause django actually has a trademark, so we might at least be able to force you legally to hand it over
[11:37:35] <dstufft> psi29a: more or less yes, I have no idea if the policy will change or not but either that or changing the name are your possible courses of actions that let you move forward in some way
[11:38:09] <dstufft> apollo13: I think the most you could compel us to do is to taking it down and preventing other people from using it, a trademark doesn't grant you the legal right to use PyPI
[11:39:17] <apollo13> dstufft: yes but that would be enough, since it would tell people that this is no longer the correct repo -- as annoying as it would be…
[11:39:40] <dstufft> FWIW I don't think the new policy forbids disabling projects all together (although we have no actual mechanism for doing so)
[11:41:20] <dstufft> enforced namespaces are an idea, I'm not particularly a fan of them, but PyPI doens't prevent you from making namespaces yourself (although i'd like to make it possible to assign permissions to a namespace so that random people can't upload as them
[11:42:25] <dstufft> I think the downside is that enforced namespaces make the common case more verbose/ugly in order to make the uncommon case easier
[11:42:46] <tomprince> Although ... it would be nice to *disable* at least, the existing ldaptor, at least if you don't specify a revision.
[11:43:26] <dstufft> apollo13: yea, I have ~plans~ to add the ability to register entire namespaces, using the name.* qualifier, but not concrete plans so I don't know how it'd work exactly
[11:44:17] <dstufft> twisted-ldaptor, twisted_ldaptor, twisted.ldaptor are all equivilant except in which name is used as the "display" name
[11:45:09] <dstufft> although I think Twisted generally doesn't want people to use twisted-whatever (maybe that doesn't matter since this is a twisted project now?)
[11:45:45] <psi29a> dstufft: it is a twisted project now, officially, kissed by Glyph, but I can ask him on the ML just in case.
[11:45:47] <dstufft> psi29a: correctly, PypI treats those 3 as equiv, ``pip install <any of those options>`` will give you the same project, and registering one effecitively registers them all
[11:47:24] <dstufft> psi29a: there are currently no mechanisms for disabling a project on PyPI. What to do about cruft in PyPI I think is an unanswered question
[11:48:14] <psi29a> and if Anton comes back up for air... he can either hand over maintainership to Glyph and myself or add us co-maintainers?
[11:50:35] <dstufft> If he comes back he can absolutely hand over the reins, there is no direct capability for redirect but you can make it clear in the project description, and you can even upload an empty package which does nothing but rely on the twisted-ldaptor package
[11:52:52] <dstufft> we'd email the contacts we had, wait awhile, and if no response and it appeared inactive we'd transfer ownership
[11:53:03] <psi29a> I would assume you'd look at the commit history of the project, but anton's fork was his... and no one contested it
[11:54:16] <dstufft> it was brought up in that thread that the first person to contact PyPI is not nescarily the correct person to get control of a project (and often there is no correct person, the project that prompted the change, django-registration has severeal hundred forks on bitbucket I believe, with more than one being actively worked on)
[11:54:18] <psi29a> My concern is that as django-registration is the leading package for handling system registration for Python's most popular web framework, handing it over without a full investigation of not just the current maintainer but also the candidate maintainer is risky.
[11:56:18] <dstufft> Richard goes into detail in a later email, he did email the current maintainer and didnt' get a response back, unfortinately he used the address he knew of for that maintainer and not the address registered in PyPI (for various reasons, the largest being he was in an airport and PyPI has no real admin interface so getting the email address of a user is non-trivial amount of effort)
[11:56:52] <dstufft> it so happened that the email address he used was a sort of public, "this is where lots of crap I don't care about goes" email for the maintainer who didn't see the email
[11:57:52] <dstufft> Then the rest more or less boils down to human beings are flawed and not enough effort was put into it in this particular case
[11:58:28] <dstufft> which sparked that thread ^ and where a number of people raised concerns about the practice of transfering names at all without consent of the maintainer
[11:58:33] <psi29a> I'll send an email to see about getting a better policy in place and see about getting twisted-ldaptor off the ground.
[12:31:54] <tomprince> dstufft: In the context of https://github.com/antong/ldaptor/issues/4#issuecomment-29169483 (and https://github.com/antong/ldaptor/issues/10#issuecomment-47226336), https://github.com/antong/ldaptor/issues/4#issuecomment-51236684 seems to be an approval for transfering the pypi name.
[21:46:39] <nanonyme> In other words, I still haven't figured out why the heck my Windows pip 1.5.6 can't be executed as python -mpip