This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author michael.mulich
Recipients Peter.Waller, alexis, carljm, eric.araujo, higery, meatballhat, michael.mulich, tarek
Date 2011-07-11.15:17:17
SpamBayes Score 1.7852334e-07
Marked as misclassified No
Message-id <1310397438.69.0.52541021819.issue8668@psf.upfronthosting.co.za>
In-reply-to
Content
After looking over the use cases, these are my findings and questions:

* Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them into a single use case. I agree with case 2 and 6 most, but have questions:
** Why wouldn't one simply use a virtualenv? -- Case 5 touches on this topic, but if we are installing in-place, who cares if can place a development package in the global site-packages directory?
** After the package has been installed in-place (using the develop command), how does one identify it as an in development project (or in development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), but doesn't explain what type of action is intended. So if we install in-place (aka, develop), how does the python interpreter find the package? Are we using PYTHONPATH at this point (which would be contradict a requirement in  case 6)?

* Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote changes (hg pull --update) for these mercurial server plugins then running the develop command on them? 

* Case 1 is good and very clear, but I'd consider it a feature rather than required. Perhaps it should not be focused on first (priority). Thoughts?
History
Date User Action Args
2011-07-11 15:17:18michael.mulichsetrecipients: + michael.mulich, tarek, carljm, eric.araujo, meatballhat, Peter.Waller, alexis, higery
2011-07-11 15:17:18michael.mulichsetmessageid: <1310397438.69.0.52541021819.issue8668@psf.upfronthosting.co.za>
2011-07-11 15:17:18michael.mulichlinkissue8668 messages
2011-07-11 15:17:17michael.mulichcreate