what about a develop command for editable installs?

5 views
Skip to first unread message

RonnyPfannschmidt

unread,
Aug 19, 2010, 9:56:46 AM8/19/10
to The fellowship of the packaging
Hi,

One thing i'm still missing from distutils2 is a develop command that
does at least the linking part the setuptools/distribute equivalent
does.

What place should such a command have in the distutils2 ecosystem?
build-in? shipped by tools?

regards Ronny

Alexis Métaireau

unread,
Aug 23, 2010, 1:10:50 PM8/23/10
to the-fellowship-...@googlegroups.com
Le 08/19/2010 03:56 PM, RonnyPfannschmidt a �crit :
> Hi,
Hi Ronny,

Sorry for the late response. Firstly, I'm not sure to be the most
accurate person to answer this question, but I'll expose here my feeling
about this, maybe others answers will follow.


> One thing i'm still missing from distutils2 is a develop command that
> does at least the linking part the setuptools/distribute equivalent
> does.

IIUC, this command goal is to provide an environment for developers, to
hack on the files, instead of installing them. I'm not sure to
understand what is the linking you're talking about, but I suppose it's
a way to have a development release "hackable".

My opinion is that such command place *is* in distutils2, at least a
simple version of this, as it seems to be an important feature to have.
It will be too bad if all the installer tools implements their own way
to do that.

Cheers,
Alexis


RonnyPfannschmidt

unread,
Aug 23, 2010, 4:02:56 PM8/23/10
to The fellowship of the packaging


On Aug 23, 7:10 pm, Alexis Métaireau <ale...@notmyidea.org> wrote:
>  Le 08/19/2010 03:56 PM, RonnyPfannschmidt a crit :> Hi,
>
> Hi Ronny,
>
> Sorry for the late response. Firstly, I'm not sure to be the most
> accurate person to answer this question, but I'll expose here my feeling
> about this, maybe others answers will follow.> One thing i'm still missing from distutils2 is a develop command that
> > does at least the linking part the setuptools/distribute equivalent
> > does.
>
> IIUC, this command goal is to provide an environment for developers, to
> hack on the files, instead of installing them. I'm not sure to
> understand what is the linking you're talking about, but I suppose it's
> a way to have a development release "hackable".
practically its setting up *.pth files and/or whatever is needed to
get the package importable
since the new file location handling stuff is on the way i suppose it
also needs path rewiring on that
>
> My opinion is that such command place *is* in distutils2, at least a
> simple version of this, as it seems to be an important feature to have.
> It will be too bad if all the installer tools implements their own way
> to do that.
linking the pth files and installing stub scripts that call the real
scripts seems reasonable for a simple buildin version
there could also be a external "standard" package for dealing with
more complex stuff like packages in user-defined locations of packages
and file locations
>
> Cheers,
> Alexis

Regards,
Ronny

Éric Araujo

unread,
Aug 24, 2010, 12:03:48 PM8/24/10
to the-fellowship-...@googlegroups.com
The goal is to install a .pth file in a directory on sys.path (with
Python >= 2.6, --user gives that for free), right? IMNSHO, this should
be implemented as an option to the install_lib* command, named
--link-only or something better.

* Not install, since .pth does not handle scripts, headers or data. The
purpose of this command/option is to make modules and packages
importable, more would be trickier.

(“pythonx.y setup.py install_lib --user --link-only” is long, I agree.
This problem is solved with copy/paste, shell history, shell function,
or we could steal the aliases system from setuptools.)

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.

This discussion should be summed up on http://bugs.python.org/issue8668
and continued there, for the sake of openness and non-repetition.

Regards

P.S. Terminology fun: you say “editable installs” because of your Pip
background, I think, whereas I think “installed source trees”, with the
reverse viewpoint :)

Reply all
Reply to author
Forward
0 new messages