Differences between revisions 1 and 5 (spanning 4 versions)

Some use cases of the 'develop' command

The 'develop' command is used to pseudo-install a project source without copying any files, which is a useful feature of setuptools and will be implemented for packaging.

However, different people may have different purposes and will use 'develop' in a very different way, so even though we argued a lot in the mailing list but have not yet reach an extensive consensus on how the future 'develop' of packaging should behave.

Thus this page is created just to collect different use cases being talked about in our fellowship list, which will be taken as an important idea base to implement an elegant solution that work for all at the most extent.

Note: These use cases are not complete and people can help me enhance.

Use Case 1 (from Carl)

Story Description: Carl has a foobar project which contains a 'foobar' directory that is referenced in his setup.{py,cfg} as the a package to be installed. He also has additional Python packages alongside 'foobar' (e.g. a 'tests' directory), which he does not want installed.

.
|-- foobar
|   |-- __init__.py
|   |-- bar.py
|   `-- foo.py
|-- setup.cfg
`-- tests
    |-- __init__.py
    |-- test_bar.py
    `-- test_foo.py

Type: Feature request

Requirements:

The 'tests' directory, or any directory not referenced in the setup.{cfg,py} for install, should not be importable, because it could have an unintended collision with other installed packages.

Use Case 2 (from Tarek)

Story Description: Tarek wants to install a project in-place with 'develop' command. Because he does not have root access to the system, therefore lacks write access to the global site-packages directory.

Questions:

Why wouldn't he simply use a virtualenv?
After the package has been installed in-place, how does one identify it as an in development project (or in development mode)?

Type: Unknown

Requirements:

The develop command cannot assume it has write access to the site-packages directory. Usage of the sudo command to install the development information is not a valid solution.

Use Case 3 (from Tarek)

Story Description:

One has a foobar project and he is in its project source tree, then he runs 'develop' in it. In addition, the virtualenv has not yet installed and he doesn't want to install it at that time.

What he wants:

foobar seems installed for him
foobar should not be shared with the whole system, or with everyone

Use Case 4 (from Carl)

Story Description: One has a private VPS that hosts a number of Mercurial repositories. In addition, he has some custom plugins and hooks that need to run for all users of the server. These plugins and hooks are frequently updated.

What he wants:

don't have to bump version numbers and make releases all the time

Use Case 5 (from Doug)

Story Description: There is a python development team and his application cann't work in a virtualenv for a variety of reasons.

What he wants:

install into the global site-packages in 'development mode'

Use Case 6 (from Doug)

Story Description: One is working on a foobar project and he has opened a python intepreter(we call it INTPT-A).

What he wants:

all applications using INTPT-A can see foobar, without having to use an environment variable
don't need to manually edit any files to configure the path for INTPT-A
any application using INTPT-A doesn't need to be run from its particular directory on the filesystem in order to see the changes or his package
all entry points, including console scripts, are registered correctly with INTPT-A
can edit files in his project and re-run the intepreter to have the changes picked up, without having to redo the 'python setup.py develop' or 'pysetup.py develop' step

-  ⇤ ← Revision 1 as of 2011-06-24 02:52:52 → 
  Size: 3587
  Editor: 180
  Comment:
+   ← Revision 5 as of 2011-07-11 14:28:07 → ⇥
  Size: 3968
  Editor: 64
  Comment: Clarifying use case two.
-Deletions are marked like this.
+Additions are marked like this.
 Line 9:
-Note: These use cases is not complete and people can help me enhance it.
+Note: These use cases are not complete and people can help me enhance.
 Line 12:
-== Use Case 1(from Eric): ==
+== Use Case 1 (from Carl) ==
 Line 15:
-One has clones of a spamproject and hamlib in different directories, and spamproject depends on hamlib.
+Carl has a foobar project which contains a 'foobar' directory that is referenced in his setup.{py,cfg} as the a package to be installed.  He also has additional Python packages alongside 'foobar' (e.g. a 'tests' directory), which he does not want installed.
 Line 17:
-'''What he wants:'''
+{{{
.
|-- foobar
|   |-- __init__.py
|   |-- bar.py
|   `-- foo.py
|-- setup.cfg
`-- tests
    |-- __init__.py
    |-- test_bar.py
    `-- test_foo.py
}}}
-Line 19:
+Line 30:
- * make hamlib visible to the Python used to run, e.g. the test suite of spamproject without installing hamlib
+'''Type:'''
Feature request
-Line 21:
+Line 33:
- * hamlib should be just importable from spamproject; any other invocation of Python would not find hamlib
+'''Requirements:'''
-Line 23:
+Line 35:
-== Use Case 2(from Carl): ==
+ * The 'tests' directory, or any directory not referenced in the setup.{cfg,py} for install, should not be importable, because it could have an unintended collision with other installed packages.

== Use Case 2 (from Tarek) ==
-Line 26:
+Line 40:
-One has a foobar project in which a 'foobar' directory is the one his setup.{py,cfg} actually supposed to install, but he also has additional Python packages alongside 'foobar', e.g. a 'tests' directory.
+Tarek wants to install a project in-place with 'develop' command. Because he does not have root access to the system, therefore lacks write access to the global site-packages directory.
-Line 28:
+Line 42:
-'''What he wants:'''
+'''Questions:'''
 * Why wouldn't he simply use a virtualenv?
 * After the package has been installed in-place, how does one identify it as an in development project (or in development mode)?
-Line 30:
+Line 46:
- * 'tests' should not be importalbe, because it's not what he really wants
+'''Type:'''
Unknown
-Line 32:
+Line 49:
-== Use Case 3(from Tarek): ==
+'''Requirements:'''
 * The develop command cannot assume it has write access to the site-packages directory. Usage of the sudo command to install the development information is not a valid solution.
-Line 34:
+Line 52:
-'''Story Description:'''
One wants to install something inplace with 'develop' command.

'''What he wants:'''
 * does not need to run sudo to install, which means 'develop' will not touch the site-packages at all

== Use Case 4(from Tarek): ==
+== Use Case 3 (from Tarek) ==
-Line 50:
+Line 62:
-== Use Case 5(from Carl): ==
+== Use Case 4 (from Carl) ==
-Line 58:
+Line 70:
-== Use Case 6(from Doug): ==
+== Use Case 5 (from Doug) ==
-Line 66:
+Line 78:
-== Use Case 7(from Doug): ==
+== Use Case 6 (from Doug) ==
-Line 76:
+Line 88:
- * can edit files in his project and re-run the intepreter to have the changes picked up, without having to redo the 'python setup.py develop' or 'pysetup develop' step
+ * can edit files in his project and re-run the intepreter to have the changes picked up, without having to redo the 'python setup.py develop' or 'pysetup.py develop' step

Page

User

Some use cases of the 'develop' command

Use Case 1 (from Carl)

Use Case 2 (from Tarek)

Use Case 3 (from Tarek)

Use Case 4 (from Carl)

Use Case 5 (from Doug)

Use Case 6 (from Doug)