Question about the 'develop' command
shoulderhigher
I want to take the 'SetuptoolsFeatures' as my Google summer
project, in which a basic requirement is to add a 'develop' command
for the Distutils2. I have read the developer documents of setuptools
and found that it also has a 'develop' command, so I think there will
be many spirits and thoughts that we can learned from such solution in
setuptools. Setuptools allows developer to deploy his projects for use
in a common directory or staging area, but without copying any files.
In addition, it creates a special .egg-link file in the deployment
directory, that links to the project's source code.
But I'm still wondering what is the usage of such directory and
how does it work as expected?
I'm preparing my application these days, so I just want to make
it clear that what's the key point of the 'develop' command of
Disutils2. Hope someone can give me helps, thank you very much.
Best wishes,
higery
Carl Meyer
On 03/30/2011 11:56 AM, shoulderhigher wrote:
> I want to take the 'SetuptoolsFeatures' as my Google summer
> project, in which a basic requirement is to add a 'develop' command
> for the Distutils2. I have read the developer documents of setuptools
> and found that it also has a 'develop' command, so I think there will
> be many spirits and thoughts that we can learned from such solution in
> setuptools. Setuptools allows developer to deploy his projects for use
> in a common directory or staging area, but without copying any files.
> In addition, it creates a special .egg-link file in the deployment
> directory, that links to the project's source code.
> But I'm still wondering what is the usage of such directory and
> how does it work as expected?
In terms of importing the packages that you "setup.py develop", the
egg-link file is actually irrelevant. When you "setup.py develop"
setuptools also adds an entry to the easy-install.pth file in the
site-packages directory, pointing to the source code location. Python
processes these pth files at startup (in the stdlib "site.py" module")
and adds paths contained in them to sys.path (see the documentation for
the site module: http://docs.python.org/library/site.html).
It's worth noting that this pth file technique generally works in most
cases, but it isn't very careful to mirror what will happen with a real
installation. If you have additional Python packages alongside the one
that your setup.py is actually supposed to install, those additional
packages will also be available as top-level imports on sys.path after
you "setup.py develop." This can be a bit surprising if they have
generic names (e.g. "tests"), and it can also hide bugs in your setup.py
(if it doesn't actually install all the packages/modules it should,
they'll still be importable under "setup.py develop" anyway). So it
might be worth putting some thought into possible ways we could improve
on setuptools' implementation of "setup.py develop" - for instance, on
platforms that support it, symlinking might be a much better approach.
Also, handling of data-files will be a tricky area.
The .egg-link file is not used by Python itself at all, but is used by
setuptools to be able to detect the develop-installed project later if
you use the APIs in pkg_resources to get the full "working set" of
installed projects.
Hope this helps gives some pointers for further digging! Good luck on
your GSoC application.
Carl
Tarek Ziadé
besides what Carl said, my first idea on this was to work on a develop
command that :
- works with the notion of "project environment"
- have one pth file per project in the user home
- allow the addition or removal of directories in those pth files
- allow the activation of one "project environment" by using
environment variables
Technically speaking, it means:
- generating .dist-info dirs in place
- read the setup,cfg files to detect what the project contains in
order to link the scrips etc
But that's just a first braindump.
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
Xu Dehai
Many thanks for Carl and Tarek's response.
If I have used 'develop' command to install a project, then how should I do if I want to take a look at what such software or package will perform after some modifications on its source code.
Document says that we can rerun develop command after we make any changes to setup script or C extensions to make things up-to-date; does it means that old files will be replaced with modified ones?
Best wishes,
higery
higery
These days I have time to consider your opinions more carefully, and I still have some questions according to your following thought.
- works with the notion of "project environment"
- have one pth file per project in the user home
- allow the addition or removal of directories in those pth files
- allow the activation of one "project environment" by using
environment variables
Technically speaking, it means:
- generating .dist-info dirs in place
- read the setup,cfg files to detect what the project contains in
order to link the scrips etc
Best regards,
higery
Floris Bruynooghe
On 30 March 2011 17:55, Tarek Ziadé <ziade...@gmail.com> wrote:
> besides what Carl said, my first idea on this was to work on a develop
> command that :
>
> - works with the notion of "project environment"
> - have one pth file per project in the user home
> - allow the addition or removal of directories in those pth files
> - allow the activation of one "project environment" by using
> environment variables
[...]
> But that's just a first braindump.
I've always been scared to terrified of setuptools' use of .pth files
so would be rather keen to avoid this situation in d2/packaging. As I
understand it you propose the .pth files to only contain directories
rather then magic (in the form of "import" lines in them), which is
obviously a much better start. Still, I wonder if it is worth taking
a step back and thinking about the problem it tries to solve.
As I understand it what it tries to solve is to have the packages and
modules of the distribution you're developing available in your
interpreter environment, i.e. on sys.path. This this to make it more
convenient when you're developing two depending packages together. To
me this is essentially managing PYTHONPATH for you.
The first question coming to mind then is that it overlaps with uses
of virtualenv or the like. So is this a feature that should live
there (which just leaves creating .dist-info in place as d2's job)?
Or should d2 perhaps have it's own mini-virtualenv like shell
modification which basically exports PYTHONPATH and prepends some
directories to it. The benefit of something like that is that it does
not change the normal non-development environment of the user.
Maybe there's other neat solutions here which might be better, but for
now I'm just wondering if I'm the only one to think that maybe it's
worth looking behind just copying setuptools develop command.
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Éric Araujo
>> - allow the activation of one "project environment" by using
>> environment variables
> Automatically by Python or manually?
“By using environment variables” means it’s a manual shell operation.
It happens before Python is run. “Activation” is a virtualenv concept
though, not a setuptools one IIRC.
>> - generating .dist-info dirs in place
> .dist-info dirs is just used by 'uninstall' command in Distutils2,
> right?
Nope. Go back to PEP 376 :)
>> - read the setup,cfg files to detect what the project contains in
>> order to link the scrips etc
> Does setup.cfg files have anything to do with import functionality?
> Accoring to your above thought of .pth files per project, we can
> import the module as expect now; it seems that there is not a
> necessarity to read the setup.cfg.
You’re right; setup.cfg lists the modules (.py files, packages,
extension modules written in C) and scripts contained in the project;
the .pth file is what will let Python find the modules. Search for
“pth” in the Python docs and stdlib (modules site and maybe pkgutil
too).
Éric Araujo
Thanks Floris for your feedback on this.
> I've always been scared to terrified of setuptools' use of .pth files
Rightly so.
> so would be rather keen to avoid this situation in d2/packaging. As
> I
> understand it you propose the .pth files to only contain directories
> rather then magic (in the form of "import" lines in them), which is
> obviously a much better start.
I personally will not accept any code that abuses “import” support in
pth files to execute arbitrary code :) There’s got to be a better way,
given that we can edit things in site.py and other standard library
modules.
> Still, I wonder if it is worth taking a step back and thinking about
> the problem it tries to solve.
>
> As I understand it what it tries to solve is to have the packages and
> modules of the distribution you're developing available in your
> interpreter environment, i.e. on sys.path. This this to make it more
> convenient when you're developing two depending packages together.
Yes.
> To me this is essentially managing PYTHONPATH for you.
It’s more than PYTHONPATH: the environment variable only persists in
one shell (unless you set it in your shell config file, but let’s not do
that from Python code), whereas pth files are created once and found by
any Python in any shell (or without any shell).
To restate the problem as I understand it: I have clones of spamproject
and hamlib in different directories, spamproject depends on hamlib, so I
need a way to make hamlib visible to the Python used to run e.g. the
test suite of spamproject, but I don’t want to install hamlib.
> The first question coming to mind then is that it overlaps with uses
> of virtualenv or the like. So is this a feature that should live
> there (which just leaves creating .dist-info in place as d2's job)?
There is some overlap in goals, yes. Your mention of virtualenv made
me think of a limitation of the develop feature: it’s not isolated! I
want to make hamlib importable from spamproject, but I may not want any
invocation of Python to find hamlib, because of startup speed issues of
version conflicts. So here’s an idea: an option to the develop command
to control where to install the pth file. (I’m not sure if this is the
same than setuptools’ egg-path option to develop.)
> Or should d2 perhaps have it's own mini-virtualenv like shell
> modification which basically exports PYTHONPATH and prepends some
> directories to it.
I don’t think it’s possible to add shell-specific code in the stdlib.
Also note that a subset of virtualenv’s functionality is being added to
CPython 3.3, unrelated to packaging.
> Maybe there's other neat solutions here which might be better, but
> for
> now I'm just wondering if I'm the only one to think that maybe it's
> worth looking behind just copying setuptools develop command.
Sure! There’s still a bit of time before the coding period starts, we
can discuss. The key thing is to provide users with the same useful
features as develop, but we’re free to improve, extend or limit the
scope and implementation.
higery
“By using environment variables” means it’s a manual shell operation. It happens before Python is run. “Activation” is a virtualenv concept though, not a setuptools one IIRC.
I think such environment variables should be added by 'python setup.py develop' command.
Since 'Activation' is a virtualenv concept, then it maybe necessary to add an option to develop command, right? For instance, "python setup.py develop --activate" makes sense.
Best regards,
higery
Éric Araujo
>> “By using environment variables” means it’s a manual shell operation. It
>> happens before Python is run. “Activation” is a virtualenv concept though,
>> not a setuptools one IIRC.
> I think such environment variables should be added by 'python setup.py
> develop' command.
If it’s technically possible for Python to set variables in the calling
shell in a way that works across platforms and shells, sure, it will be
a nice extra functionality. I think you should first focus on the
specification of develop itself.
> Since 'Activation' is a virtualenv concept, then it maybe necessary to add
> an option to develop command, right?
With that comment I didn’t want to talk about implementation details,
just to say that you won’t find mentions of activation in the setuptools
code or docs because it’s a virtualenv feature.
Cheers
Floris Bruynooghe
> I personally will not accept any code that abuses “import” support in pth
> files to execute arbitrary code :)
Glad to hear!
> To restate the problem as I understand it: I have clones of spamproject and
> hamlib in different directories, spamproject depends on hamlib, so I need a
> way to make hamlib visible to the Python used to run e.g. the test suite of
> spamproject, but I don’t want to install hamlib.
ack
>> The first question coming to mind then is that it overlaps with uses
>> of virtualenv or the like. So is this a feature that should live
>> there (which just leaves creating .dist-info in place as d2's job)?
>
> There is some overlap in goals, yes. Your mention of virtualenv made me
> think of a limitation of the develop feature: it’s not isolated! I want to
> make hamlib importable from spamproject, but I may not want any invocation
> of Python to find hamlib, because of startup speed issues of version
> conflicts.
Indeed, the isolation issue is one of the niggles I have with it.
When I develop myself I often have a released version in the user
site-packages but put an in-development version on sys.path somehow
(I'm clearly not using the develop command currently ;-)).
> So here’s an idea: an option to the develop command to control
> where to install the pth file. (I’m not sure if this is the same than
> setuptools’ egg-path option to develop.)
Here's another idea which came to mind when reading your version of
the problem description: tell the setup.{py,cfg} of spamproject where
the directory of the hamlib you want is. Then the test command can
ensure the dist-info files of hamlib are build and add it to the
sys.path during the test run, keeping it completely isolated.
Similarly the develop command could then start you an interactive
python interpreter with sys.path set (and dist-info created) so you
can reach both hamlib and spamproject. But when you leave that
interpreter it's all gone again. None of this requires any .pth
files!
I realise that having to specify the location of hamlib in spamproject
might be a sticking point.
Carl Meyer
> On 11 May 2011 16:52, Éric Araujo <win...@netwok.org> wrote:
>> To restate the problem as I understand it: I have clones of spamproject and
>> hamlib in different directories, spamproject depends on hamlib, so I need a
>> way to make hamlib visible to the Python used to run e.g. the test suite of
>> spamproject, but I don’t want to install hamlib.
I don't agree with this as a problem statement for the "develop"
command. Spamproject is irrelevant, and introducing it into the problem
statement just confuses the purpose of "develop". A "develop" command
that is only usable for this use case, e.g. if its used via the
setup.cfg of spamproject, does not meet my use cases for "develop",
which don't necessarily involve dependencies of other projects at all.
IMO the problem statement for a "develop" command is simply this: I want
an in-place install. In other words, "develop" should function just like
a real installation of the package, in that it should be considered
installed for all purposes including dependency computation, scripts
should be available, and all modules and packages should be importable,
but the source code should not be copied to any other location; changes
made to the original source tree should be immediately available for
import. And it should not depend on transient modification of my shell,
either - it should be a persistent condition on the filesystem that is
reversed only if I explicitly ask for the "develop"-installed project to
be uninstalled.
The current setuptools feature meets these requirements, except that the
actual importability of packages and modules is simplistic and doesn't
work with complex uses of the "package_dir" keyword arg. I'd hope we
could make the d2 version more robust.
>>> The first question coming to mind then is that it overlaps with uses
>>> of virtualenv or the like. So is this a feature that should live
>>> there (which just leaves creating .dist-info in place as d2's job)?
>>
>> There is some overlap in goals, yes. Your mention of virtualenv made me
>> think of a limitation of the develop feature: it’s not isolated! I want to
>> make hamlib importable from spamproject, but I may not want any invocation
>> of Python to find hamlib, because of startup speed issues of version
>> conflicts.
No. "Lack of isolation" is NOT a limitation of "setup.py develop". It's
an orthogonal concern which is already handled perfectly adequately by
virtualenv (which hopefully we'll have in the stdlib for 3.3). There is
no reason why "setup.py develop" should scope-creep and gain
isolation-related features; it should simply be concerned with
performing an in-place installation, and should not care about the
destination of that installation, any more than a regular pysetup
install does.
To address the mentioned use case, you should simply create a virtualenv
called "spamproject-test" and then "develop"-install hamlib into that
virtualenv, rather than trying to pollute develop-install with
half-baked virtualenv-like features.
> Indeed, the isolation issue is one of the niggles I have with it.
> When I develop myself I often have a released version in the user
> site-packages but put an in-development version on sys.path somehow
> (I'm clearly not using the develop command currently ;-)).
Once again, virtualenv can already handle this just fine.
>> So here’s an idea: an option to the develop command to control
>> where to install the pth file. (I’m not sure if this is the same than
>> setuptools’ egg-path option to develop.)
>
> Here's another idea which came to mind when reading your version of
> the problem description: tell the setup.{py,cfg} of spamproject where
> the directory of the hamlib you want is. Then the test command can
> ensure the dist-info files of hamlib are build and add it to the
> sys.path during the test run, keeping it completely isolated.
> Similarly the develop command could then start you an interactive
> python interpreter with sys.path set (and dist-info created) so you
> can reach both hamlib and spamproject. But when you leave that
> interpreter it's all gone again. None of this requires any .pth
> files!
Please, no. This is just scope confusion all over the place, IMO.
"Develop" should not be tied to testing, and it should not be temporary,
and it should not be tied to some other packages setup.cfg. Any one of
these changes would make "develop" useless for the majority of my
current (daily) use of it.
Pth files are actually perfectly built for the use case of "develop",
and I think we should use them for it. Using them does not require
abusing them with executable code, like setuptools does (just to force
its eggs to the top of sys.path, which is unnecessary and anti-social IMO).
Carl Meyer
On Mar 30, 11:55 am, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
> besides what Carl said, my first idea on this was to work on a develop
> command that :
>
> - works with the notion of "project environment"
> - have one pth file per project in the user home
> - allow the addition or removal of directories in those pth files
> - allow the activation of one "project environment" by using
> environment variables
environment" and activation of them seems like a half-baked re-
implementation of virtualenv, and I don't see the point of that. I
already use virtualenv and will continue to use it, I don't want d2 to
start trying to manage these pseudo-virtualenvs on my behalf. That
will just make my workflow more complicated and difficult.
Basically, I want something much closer to setuptools' existing
develop-install, just tweaked a bit for robustness. Setuptools'
existing approach is widely used and useful; I don't see why it needs
this complete re-thinking.
Carl
Éric Araujo
Thanks Carl for weighing in and clearing some misconceptions of mine.
Le 15/05/2011 16:40, Carl Meyer a écrit :
> On 05/15/2011 05:51 AM, Floris Bruynooghe wrote:
>> On 11 May 2011 16:52, Éric Araujo <win...@netwok.org> wrote:
> IMO the problem statement for a "develop" command is simply this: I want
> an in-place install. In other words, "develop" should function just like
> a real installation of the package, in that it should be considered
> installed for all purposes including dependency computation, scripts
> should be available, and all modules and packages should be importable,
> but the source code should not be copied to any other location; changes
> made to the original source tree should be immediately available for
> import.
Okay. I tried to think about more defined use cases that “I want an
in-place install”, i.e. think about why you want that and whether there
are solutions for those use cases that may have a user interface and an
implementation quite different than the setuptools develop command, but
I now think I was wrong, and your restatement of the feature is what we
should start with. (You forgot to mention that dist-info API should
find the distribution too.)
> And it should not depend on transient modification of my shell
Agreed.
> The current setuptools feature meets these requirements, except that the
> actual importability of packages and modules is simplistic and doesn't
> work with complex uses of the "package_dir" keyword arg. I'd hope we
> could make the d2 version more robust.
For one thing, there’s only one package_root option in d2 (it applies to
modules too), so with less complexity and more tests we can get to
confident robustness.
(I’d like to kill the “root package” concept in the d2 docs and just
talk about the top level for modules instead.)
> No. "Lack of isolation" is NOT a limitation of "setup.py develop". It's
> an orthogonal concern which is already handled perfectly adequately by
> virtualenv (which hopefully we'll have in the stdlib for 3.3).
Thanks for stating clearly it’s orthogonal. +1 on not concerning us
with that.
> Pth files are actually perfectly built for the use case of "develop",
> and I think we should use them for it. Using them does not require
> abusing them with executable code, like setuptools does
Good to hear you confirm it’s feasible.
Higery: Have you searched the ML archives for “develop”? There were one
of two starts of discussion about it, during the last of which I said:
> I have a suspicion the install command (or a subcommand) already has
> most of what it takes to do this. I’m still trying to understand the
> extra_path argument (http://bugs.python.org/issue901727), which may or
> may not give us 90% of what’s needed to implement this feature.
Cheers
Carl Meyer
On 05/18/2011 12:07 PM, Éric Araujo wrote:
> Okay. I tried to think about more defined use cases that “I want an
> in-place install”, i.e. think about why you want that and whether there
> are solutions for those use cases that may have a user interface and an
> implementation quite different than the setuptools develop command,
Sure, that's a reasonable thing to do.
> but
> I now think I was wrong, and your restatement of the feature is what we
> should start with.
Good. :-)
> (You forgot to mention that dist-info API should
> find the distribution too.)
Yes.
>> The current setuptools feature meets these requirements, except that the
>> actual importability of packages and modules is simplistic and doesn't
>> work with complex uses of the "package_dir" keyword arg. I'd hope we
>> could make the d2 version more robust.
> For one thing, there’s only one package_root option in d2 (it applies to
> modules too), so with less complexity and more tests we can get to
> confident robustness.
>
> (I’d like to kill the “root package” concept in the d2 docs and just
> talk about the top level for modules instead.)
Excellent, I hadn't followed that discussion. That will make things a
lot simpler.
>> Pth files are actually perfectly built for the use case of "develop",
>> and I think we should use them for it. Using them does not require
>> abusing them with executable code, like setuptools does
> Good to hear you confirm it’s feasible.
If we needed to support complex package_dir hierarchies, we might need
multiple pth entries. But if there's just one package_root, having that
root in a pth file should be sufficient.
One remaining issue with using pth this way is that it's possible for
"develop" to give you more stuff importable than you actually want, if
you have Python modules/packages under your package_root, but excluded
in your setup.cfg. This would be an advantage of symlinks, in that we
could just symlink over the specific packages/modules listed in
setup.cfg. But I'm not sure the "extra stuff" problem is really that big
a deal; it's probably not worth two separate implementations of
"develop", one for OSes with symlink and one for those without.
> Higery: Have you searched the ML archives for “develop”? There were one
> of two starts of discussion about it, during the last of which I said:
>
>> I have a suspicion the install command (or a subcommand) already has
>> most of what it takes to do this. I’m still trying to understand the
>> extra_path argument (http://bugs.python.org/issue901727), which may or
>> may not give us 90% of what’s needed to implement this feature.
Looking forward to your work on this feature, Higery!
Carl
higery
Higery: Have you searched the ML archives for “develop”? There were one
of two starts of discussion about it, during the last of which I said:
> I have a suspicion the install command (or a subcommand) already has
> most of what it takes to do this. I’m still trying to understand the
> extra_path argument (http://bugs.python.org/issue901727), which may or
> may not give us 90% of what’s needed to implement this feature.
Yes, I paid attention to your discussing in bug tracker(Issue 8668).
These days' talk about develop command in this thread have helped me a lot and made me more clear to know what I should do in future coding days.
Best wishes to everyone here,
higery
higery
Looking forward to your work on this feature, Higery!
Best regards,
higery
Éric Araujo
I have another question about the develop command for people who use it
a lot. What do you think about the name? Do you want to keep it as is,
to make clear it’s the same thing as the setuptools command (but working
with packaging/distutils2), or are you open to finding a better name?
I say better because to me, develop is not a great description.
Developing is what I do with my text editor, my VCS and my bug tracker.
This command is in my eyes a kind of install command.
Thoughts?
Michael Foord
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
Carl Meyer
Pip uses the term "editable", which I think makes some sense. But really
all the variations including "install" that I can think of end up being
long and unwieldy: "install_editable"? Ugh. One word is better than two.
Really, "develop" is not a bad name, and I think there's some benefit to
continuity of terminology with setuptools when there isn't a good reason
for a break.
Carl
Erik Bray
>
>
> On 15 June 2011 15:45, Éric Araujo <win...@netwok.org> wrote:
>>
>> Hi folks,
>>
>> I have another question about the develop command for people who use it
>> a lot. What do you think about the name? Do you want to keep it as is,
>> to make clear it’s the same thing as the setuptools command (but working
>> with packaging/distutils2), or are you open to finding a better name?
>>
>> I say better because to me, develop is not a great description.
>> Developing is what I do with my text editor, my VCS and my bug tracker.
>> This command is in my eyes a kind of install command.
>>
>> Thoughts?
>
> To me it implies "make available the under development version", so develop
> is fine for me (and has the right connotations). But yes, it is "a kind of
> install command".
I wouldn't object to making it an option to the install command.
Something like `pysetup install --develop`. Seems simpler to me than
having an entirely different command.
Erik
Carl Meyer
> I wouldn't object to making it an option to the install command.
> Something like `pysetup install --develop`. Seems simpler to me than
> having an entirely different command.
This is what pip does (except the option is -e/--editable), and I
thought of proposing it. The issue is that this option severely
restricts the valid arguments to "install" when it's used (no PyPI
project names, just local directories), and it feels a little odd for an
option to have that effect on a command.
In pip, you can pass either a local directory or a VCS url to "install
-e". In pysetup, that would be just a local directory, since pip's VCS
backends aren't going into the stdlib.
Carl
Éric Araujo
> On 06/15/2011 11:42 AM, Erik Bray wrote:
>> I wouldn't object to making it an option to the install command.
>> Something like `pysetup install --develop`. Seems simpler to me than
>> having an entirely different command.
>
> This is what pip does (except the option is -e/--editable), and I
> thought of proposing it. The issue is that this option severely
> restricts the valid arguments to "install" when it's used (no PyPI
> project names, just local directories), and it feels a little odd for an
> option to have that effect on a command.
You’re confusing pysetup actions and pysetup commands (higery, you
too!). The things that can operate on project names, tarballs, etc. are
commands; for example, pysetup list and pysetup install. The things
that operate on a source directory with a setup.cfg are commands (just
like distutils commands), for example pysetup run build_ext and pysetup
run install_lib.
develop is a commmand, not an action, so a new install_* name or an
option to the existing install_dist command would work for me.
Regards
Pierre-Yves David
> The things that can operate on project names, tarballs, etc. are
> commands;
> The things that operate on a source directory with a setup.cfg are commands
Looks like your confused them too :-)
--
Pierre-Yves David
Éric Araujo
> On Thu, Jun 16, 2011 at 04:00:42PM +0200, Éric Araujo wrote:
>> The things that can operate on project names, tarballs, etc. are
>> commands;
>> […]
>> The things that operate on a source directory with a setup.cfg are commands
> Looks like your confused them too :-)
Ha ha :) So : The things that can operate on project names, tarballs,
etc. are actions; the things that operate on a source directory with a
setup.cfg are commands.
higery
Through the above discussion, I think there are two things that we have made clear:
1) 'develop' is just a kind of command rather than an action
2) 'develop' should not be taken as an option of install
cause we 'develop' a project just from a local source directory instead of a PYPI or VCS, and if it's an option of install, it will restrict the valid arguments to install action (from Carl's saying)
So, I agree with Eric's suggestion of taking 'develop' as a command and using a kind of install_* as its name. And for me, I will not take the 'editable' as its keyword, because 'editable' is just an option of Easyinstall in setuptools, what's more, 'editable' does not have an obvious heuristic meaning and is a little confusing.
There are two candidates:
1) install_develop
2) install_development
The second one is better in my opinion, because we should take the last word after '_' as a noun instead of a verb in packaging(e.g. install_lib, install_scripts, install_data, install_distinfo) , and 'development' will let users get a bit thought that its project will be installed in a 'development mode', which is in keeping with the saying on setuptools' online documents and comments in its source code. Look at http://peak.telecommunity.com/DevCenter/setuptools#development-mode
But we also should clarify here that, although the name of develop command takes 'install' as the prefix, install_development should not be taken as a subcommand of the install action.
Do you agree with me? Any thoughts?
Best wishes to everyone,
higery
Pierre-Yves David
> But we also should clarify here that, although the name of develop command
> takes 'install' as the prefix, install_development should not be taken as a
> subcommand of the install action.
This seems a good reason not to choose ``install_`` as a prefix for this command.
Éric Araujo
> On Wed, Jun 22, 2011 at 12:00:30AM +0800, higery wrote:
>> But we also should clarify here that, although the name of develop command
>> takes 'install' as the prefix, install_development should not be taken as a
>> subcommand of the install action.
> This seems a good reason not to choose ``install_`` as a prefix for this command.
Agreed. Let’s keep a develop command for now, and we’ll see later if
it’s better to rename it to install_dist --develop.
Michael Foord
Hi, folks:
Through the above discussion, I think there are two things that we have made clear:
1) 'develop' is just a kind of command rather than an action
2) 'develop' should not be taken as an option of install
cause we 'develop' a project just from a local source directory instead of a PYPI or VCS, and if it's an option of install, it will restrict the valid arguments to install action (from Carl's saying)
So, I agree with Eric's suggestion of taking 'develop' as a command and using a kind of install_* as its name. And for me, I will not take the 'editable' as its keyword, because 'editable' is just an option of Easyinstall in setuptools, what's more, 'editable' does not have an obvious heuristic meaning and is a little confusing.
There are two candidates:
1) install_develop
2) install_development
The second one is better in my opinion,
You're saying we should move from a seven letter command (for which I didn't see any evidence proferred that it was confusing anyone in practise) to a 14 letter one? -1
Michael
because we should take the last word after '_' as a noun instead of a verb in packaging(e.g. install_lib, install_scripts, install_data, install_distinfo) , and 'development' will let users get a bit thought that its project will be installed in a 'development mode', which is in keeping with the saying on setuptools' online documents and comments in its source code. Look at http://peak.telecommunity.com/DevCenter/setuptools#development-mode
But we also should clarify here that, although the name of develop command takes 'install' as the prefix, install_development should not be taken as a subcommand of the install action.
Do you agree with me? Any thoughts?
Best wishes to everyone,
higery
Tarek Ziadé
>
>
> On 21 June 2011 17:00, higery <shoulde...@gmail.com> wrote:
>>
>> Hi, folks:
>>
>>
>> Through the above discussion, I think there are two things that we have
>> made clear:
>>
>> 1) 'develop' is just a kind of command rather than an action
>> 2) 'develop' should not be taken as an option of install
>> cause we 'develop' a project just from a local source directory instead of
>> a PYPI or VCS, and if it's an option of install, it will restrict the valid
>> arguments to install action (from Carl's saying)
>>
>> So, I agree with Eric's suggestion of taking 'develop' as a command and
>> using a kind of install_* as its name. And for me, I will not take the
>> 'editable' as its keyword, because 'editable' is just an option of
>> Easyinstall in setuptools, what's more, 'editable' does not have an obvious
>> heuristic meaning and is a little confusing.
>>
>>
>> There are two candidates:
>> 1) install_develop
>> 2) install_development
>>
>> The second one is better in my opinion,
>
> You're saying we should move from a seven letter command (for which I didn't
> see any evidence proferred that it was confusing anyone in practise) to a 14
> letter one? -1
For the command name itself it does not really matter imo.
now I really think we want an action for this in pysetup, and well, a
pysetup install option seemed nice:
$ pysetup install --inplace
I am not sure why this would be a real problem
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
Tarek Ziadé
Because people don't want to run sudo to install something inplace..
which makes sense
Installing something inplace is something a user does for himself, so
there's a notion of "local"
How would you implement Setuptools' develop without touching the main
site-packages at all ?
>
> Carl
higery
How would you implement Setuptools' develop without touching the main
site-packages at all ?
As Tarek said, to activate a project, we will always configure the environment variables manually rather than using code, so do you think it's a little boring? We can append a path to os.environ in the source code, but it would not work across shells and platforms.
Then how about just creating a kind of 'packaing.pth' file in site-packages, and write the source directory path to it when 'develop' is used?
Regards,
higery
Carl Meyer
On 06/21/2011 06:12 PM, Tarek Ziad� wrote:
>>> - works with the notion of "project environment"
>>> - have one pth file per project in the user home
>>> - allow the addition or removal of directories in those pth files
>>> - allow the activation of one "project environment" by using
>>> environment variables
>>
>> I don't like this approach. Again, the entire concept of "project
>> environment" and activation of them seems like a half-baked re-
>> implementation of virtualenv, and I don't see the point of that. I
>> already use virtualenv and will continue to use it, I don't want d2 to
>> start trying to manage these pseudo-virtualenvs on my behalf. That
>> will just make my workflow more complicated and difficult.
>>
>> Basically, I want something much closer to setuptools' existing
>> develop-install, just tweaked a bit for robustness. Setuptools'
>> existing approach is widely used and useful; I don't see why it needs
>> this complete re-thinking.
>
> Because people don't want to run sudo to install something inplace..
> which makes sense
Which people? Is there a record of such complaints somewhere? I haven't
heard any such comments regarding pip's "install --editable", which is
just a wrapper around "setup.py develop". But if we made it impossible
to "install --editable" into system site-packages, I would guess we
would have complaints about that unnecessary restriction.
> Installing something inplace is something a user does for himself, so
> there's a notion of "local"
I don't agree. The notion of installing in-place is orthogonal to the
question of whether that install happens at the system level, the user
level, or the virtualenv level.
I have seen people use "pip install --editable" to install things in
their system Python: why would you want to outlaw such usage?
> How would you implement Setuptools' develop without touching the main
> site-packages at all ?
Why would I want to? If someone wants to develop-install something into
the system site-packages, they should be perfectly able to do that (and
it should require sudo). If they don't want to do that, they use --user
or a virtualenv. No different from a regular install.
Carl