On 29 November 2016 at 21:41, Thomas Kluyver wrote:
> On Thu, Nov 24, 2016, at 11:10 PM, Paul Moore wrote:
> But even without that, they're not ideal. I routinely have development
> installs of quite a lot of different packages. If each one of those is
> an entry on sys.path from a .pth file, ther
On Thu, Nov 24, 2016, at 11:10 PM, Paul Moore wrote:
> Honestly, I don't see what's so bad about pth files. They are a
> standard supported Python approach. Maybe setuptools' use of them is
> messy? I recall it was possible to end up with a lot of clutter, but
> that was going back to the egg days,
On 29 November 2016 at 07:23, Daniel Holth wrote:
> Here is the design. The build tool provides the install tool with a
> directory, or if you want to get fancy, a list of directories, that should
> be added to PYTHONPATH. The build tool builds into that path. The install
> tool makes sure Python
On 29 November 2016 at 04:23, Daniel Holth wrote:
> Here is the design. The build tool provides the install tool with a
> directory, or if you want to get fancy, a list of directories, that should
> be added to PYTHONPATH. The build tool builds into that path. The install
> tool makes sure Python
Here is the design. The build tool provides the install tool with a
directory, or if you want to get fancy, a list of directories, that should
be added to PYTHONPATH. The build tool builds into that path. The install
tool makes sure Python can find it. This will make anyone who uses
setuptools happ
On Mon, Nov 28, 2016 at 10:01 AM, Paul Moore wrote:
> On 28 November 2016 at 17:53, Chris Barker wrote:
> >> Why not just have a single pth file, maintained by the build
> >> tool, for all editable installs?
> >
> > shouldn't that be maintained by the install tool? i.e. pip -- the whole
> idea
>
On 28 November 2016 at 17:53, Chris Barker wrote:
>> Why not just have a single pth file, maintained by the build
>> tool, for all editable installs?
>
> shouldn't that be maintained by the install tool? i.e. pip -- the whole idea
> is that the install tool is different than the built tool, yes? a
On Thu, Nov 24, 2016 at 3:10 PM, Paul Moore wrote:
> Honestly, I don't see what's so bad about pth files. They are a
> standard supported Python approach. Maybe setuptools' use of them is
> messy?
exactly.
The fact that setuptools over-uses (abuses?) pth files doesn't mean that
they can't be u
On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith wrote:
> On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker
> wrote:
>
> > Please, please, let's figure SOMETHING our here - editable installs (or
> > "develop" installs) are a critical tool. Frankly, I don't know how anyone
> > can develop a package
I suppose a __main__.py could also/instead be added as
- site.tools.__main__
https://github.com/python/cpython/blob/master/Lib/site.py
- site.__doc__
- site._script()
- distutils.__main__
https://github.com/python/cpython/tree/master/Lib/distutils/command
- setuptools.__main__
https://
On 26 November 2016 at 19:34, Wes Turner wrote:
> On Friday, November 25, 2016, Nick Coghlan wrote:
>> By contrast, if we only propose deprecating "import" lines in ".pth"
>> files, and also propose a more explicit approach to automatic code
>> execution at interpreter startup, then it's only fol
On Friday, November 25, 2016, Nick Coghlan wrote:
> On 25 November 2016 at 12:26, Robert Collins > wrote:
> > On 25 November 2016 at 14:04, Nick Coghlan > wrote:
> >> The bad reputation of ".pth" doesn't generally stem from their normal
> >> usage (i.e. just listing absolute or relative directo
On 25 November 2016 at 12:26, Robert Collins wrote:
> On 25 November 2016 at 14:04, Nick Coghlan wrote:
>> The bad reputation of ".pth" doesn't generally stem from their normal
>> usage (i.e. just listing absolute or relative directory names that the
>> import system will then append to __path__)
On Wed, Nov 23, 2016, at 07:22 PM, Donald Stufft wrote:
> I think at a minimum we should get PEP 518 support into pip first. I
> don't think layering more things on top of a PEP that isn't yet
> implemented is a good approach to this.
I went to make a start on this, but I got stuck on whether and
actually editable installs can be made uninstallable trivially
in gumby-elf i would create a fake wheel with files inside to facilitate
the path building for namespaces,
and a local version number (so pip would create my exe files and
uninstall clean)
-- Ronny
On 24.11.2016 01:23, Daniel Holth w
On 25 November 2016 at 14:04, Nick Coghlan wrote:
..
>
> The bad reputation of ".pth" doesn't generally stem from their normal
> usage (i.e. just listing absolute or relative directory names that the
> import system will then append to __path__).
>
> Rather, it stems from this little aspect: "Line
On 25 November 2016 at 09:10, Paul Moore wrote:
> Honestly, I don't see what's so bad about pth files. They are a
> standard supported Python approach. Maybe setuptools' use of them is
> messy? I recall it was possible to end up with a lot of clutter, but
> that was going back to the egg days, I'm
Thomas Kluyver wrote:
- There's a feature called NTFS Junction Points, which is supposed to be
like symlinks, but only for directories.
Things might have changed, but last time I played with
junction points they seemed rather dangerous, because
if you deleted one using the GUI it deleted the co
On 24 November 2016 at 21:51, Thomas Kluyver wrote:
> On Thu, Nov 24, 2016, at 08:07 PM, Paul Moore wrote:
>> Just curious - how does flit handle Windows for this? Symlinks aren't
>> really an option there (you need elevation to create a symlink).
>> Paul
>
> It largely doesn't at present; it star
I've made PRs against PEP 517 for:
Underscore to dash in build-backend:
https://github.com/python/peps/pull/139
1a: Add a user parameter to the install_editable hook
https://github.com/python/peps/pull/140
OR:
1c: Get rid of the install_editable hook
https://github.com/python/peps/pull/141
I'm
On Thu, Nov 24, 2016, at 08:07 PM, Paul Moore wrote:
> Just curious - how does flit handle Windows for this? Symlinks aren't
> really an option there (you need elevation to create a symlink).
> Paul
It largely doesn't at present; it started out as a personal tool for me,
and I mostly use Linux. I
On 24 November 2016 at 19:50, Thomas Kluyver wrote:
> I hate the thing setuptools does with .pth files all over the place, so the
> equivalent operation in flit symlinks packages to site-packages.
Just curious - how does flit handle Windows for this? Symlinks aren't
really an option there (you ne
On Thu, Nov 24, 2016, at 07:50 PM, Thomas Kluyver wrote:
> I made a PR to flit to handle this case better in uninstallation.
I meant a PR to *pip*.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distuti
On Thu, Nov 24, 2016, at 12:23 AM, Daniel Holth wrote:
> I wouldn't be afraid of editable installs. They are trivial and
> involve building the package in place and putting a .pth file where it
> will be noticed. Specify editable packages can't necessarily be
> uninstalled in a standard way and yo
On 24 November 2016 at 00:32, Nathaniel Smith wrote:
> Also note that just like we decided to split the basic pyproject.toml
> proposal (now PEP 518) from the build system interface proposal (now
> PEP 517), it might (probably) makes sense to split the editable
> install part of the build system i
On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker wrote:
> On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver
> wrote:
>
>>
>> Questions:
>> 1. Editable installs. The PEP currenly specifies a hook to do an
>> editable install (like 'pip install -e' or 'setup.py develop') into a
>> given prefix. I don't
I wouldn't be afraid of editable installs. They are trivial and involve
building the package in place and putting a .pth file where it will be
noticed. Specify editable packages can't necessarily be uninstalled in a
standard way and you are done.
The bespoke build tool tells pip where the package
On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver
wrote:
> Questions:
> 1. Editable installs. The PEP currenly specifies a hook to do an
> editable install (like 'pip install -e' or 'setup.py develop') into a
> given prefix. I don't think that specifying a prefix is sufficient to
> cover '--user'
On 23 November 2016 at 19:17, Brett Cannon wrote:
> My vote is for 1c (easier to add 1a later), and dashes (for some reason I
> just like how they look more in config files).
I agree, 1c sounds like a reasonable starting place (but I don't tend
to use editable installs, so treat my views on this
Hi,
On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver wrote:
> I'd like to push PEP 517 forwards again. This PEP specifies a general
> build system interface so that a source tree can specify a tool (such as
> flit), and pip can ask that tool to generate a wheel. This would allow
> us to install fr
On Wed, Nov 23, 2016 at 2:17 PM, Brett Cannon wrote:
> My vote is for 1c (easier to add 1a later), and dashes (for some reason I
> just like how they look more in config files).
I'm glad I'm not the only one! Configuration shouldn't require the
use of the hated 'shift' key.
-Fred
--
Fred L
My 2 cents:
I think at a minimum we should get PEP 518 support into pip first. I don't
think layering more things on top of a PEP that isn't yet implemented is a good
approach to this.
Sent from my iPhone
> On Nov 23, 2016, at 9:35 AM, Thomas Kluyver wrote:
>
> I'd like to push PEP 517 forw
Thanks for starting this up again!
My vote is for 1c (easier to add 1a later), and dashes (for some reason I
just like how they look more in config files).
On Wed, Nov 23, 2016, 06:36 Thomas Kluyver, wrote:
> I'd like to push PEP 517 forwards again. This PEP specifies a general
> build system i
I'd like to push PEP 517 forwards again. This PEP specifies a general
build system interface so that a source tree can specify a tool (such as
flit), and pip can ask that tool to generate a wheel. This would allow
us to install from an sdist or a VCS checkout without running a setup.py
file.
https
34 matches
Mail list logo
