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 carljm
Recipients Peter.Waller, alexis, carljm, eric.araujo, higery, meatballhat, michael.mulich, tarek
Date 2011-07-11.17:14:03
SpamBayes Score 4.0134562e-14
Marked as misclassified No
Message-id <>
In-reply-to <>
On 07/11/2011 09:17 AM, Michael Mulich wrote:
> * 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? 

I don't know. I don't consider case 3 useful, because I don't consider
"I don't want to use a virtualenv" (without some clearer technical
justification) to be a prejudice the develop feature needs to support;
especially if supporting it essentially means re-implementing a
less-capable version of virtualenv within the develop command.

> -- 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?

Several of these stories make the assumption that even the "in-place"
installation will require placing a file in the installation location (a
.pth file, if we follow the current setuptools implementation strategy).
I think this is probably true, given the requirements in case 6 (which I
agree with). So if you want an in-place install that's globally
accessible, you'd need write access to global site-packages.

> ** 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)?

These use cases (probably intentionally) don't touch on specific
implementation strategies, but as I mentioned there's an implicit
assumption that a .pth file is the most likely strategy.

> * 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? 

Right, although the requirement for that story is that you don't have to
re-run the develop command after every pull; if you develop-install it
once, you can simply pull more code changes in and they'll immediately
be available. I've added a line to that story to make it more clear.

> * 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?

I agree that's a second-level feature (or, perhaps more accurately, a
bug in the existing setuptools feature that I was hoping could be
addressed in the d2 version), not a primary requirement.
Date User Action Args
2011-07-11 17:14:05carljmsetrecipients: + carljm, tarek, eric.araujo, meatballhat, Peter.Waller, alexis, michael.mulich, higery
2011-07-11 17:14:03carljmlinkissue8668 messages
2011-07-11 17:14:03carljmcreate