[Distutils] Re: [poposal for preparing a pep] sharing package installations between virtualenvs

Hi Freddy, Thomas thanks for the well cautioned notes. I'm vaguely aware that both, nix and conda, as "meta package managers" have a effective way of linking correct sets of packages including the tracing. however both tools never made it into a consistent set of tools that my peers, coworkers,

Re: [Distutils] [proposal] shared distribution installations

I would like to explicitly avoid Hardlink Farms because those still have "Logical" duplication i'd like to bind in the new paths without having it look like each virtualenv is 400-1000 mb of distinct data -- Ronny Am Montag, den 30.10.2017, 22:23 + schrieb Thomas Kluyver: > On Mon, Oct 30,

Re: [Distutils] [proposal] shared distribution installations

Hi Freddy, im well aware what nix currently does for python packages and suffered my fair share from it. What i want to do is simply store those wheels that pip would first generate and unpack into each environment into a location where each environment shares the unpacked files more directly

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

On 17.03.2017 15:35, Nick Coghlan wrote: > On 17 March 2017 at 19:58, Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > Hi everyone, > > while looking over the recent peps i noticed

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

btw, thats irrelevant for dist-info either it gets found double and is a problem or its priority-overridden On 17.03.2017 15:00, Paul Moore wrote: > On 17 March 2017 at 13:34, Donald Stufft wrote: >> Hmm, I believe it generally works fine does it not? The only situations I >>

[Distutils] [proposal] version-free + lookup-friendly dist-info location

Hi everyone, while looking over the recent peps i noticed that we keep a few inherent inefficiencies in where to find dist-info folders because they include version numbers, to get a distribution we have to search for it which is no longer really sensible as we no longer have multi-version

Re: [Distutils] PEP 517: Build system API

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

Re: [Distutils] [proposal] module dependency specification and overriding for packages

Hi, On 10.09.2016 12:37, Nick Coghlan wrote: On 9 September 2016 at 16:46, Ronny Pfannschmidt <opensou...@ronnypfannschmidt.de> wrote: Hi, while trying to vendor packages that depend on six, i noticed a problematic implication it is impossible to do this without patching those m

Re: [Distutils] [proposal] module dependency specification and overriding for packages

On 09.09.2016 09:37, Philippe Ombredanne wrote: On Fri, Sep 9, 2016 at 8:46 AM, Ronny Pfannschmidt <opensou...@ronnypfannschmidt.de> wrote: while trying to vendor packages that depend on six, i noticed a problematic implication it is impossible to do this without patching those m

[Distutils] [proposal] module dependency specification and overriding for packages

Hi, while trying to vendor packages that depend on six, i noticed a problematic implication it is impossible to do this without patching those modules, as such adding a fragile maintenance burden. in order to elevate that i propose creating a mechanism that allows to physically or

Re: [Distutils] Improved Stats Features in Python

Hello Rui, this mailing list deal with tools you can use to publish 3rd party packages to something like the pypi package index, if you want to add to the python stdlib, you need to get started with python-ideas, python-dev and very likely write a PEP that will have to get accepted. if

Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

Am 20.04.2016 um 00:38 schrieb Chris Barker: > On Tue, Apr 19, 2016 at 9:45 AM, Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > Instead of overtaking, > how about clearly marking packages a

Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

Instead of overtaking, how about clearly marking packages as abandoned/maintained clearly pointing out the mark was imposed by community action and listing potential/primary replacements this would have the possibility of also supporting normal abandonment when people voluntary stop maintenance

Re: [Distutils] Idea: Positive/negative extras in general and as replacement for features

Am 09.02.2016 um 22:24 schrieb Robert Collins: Sorry for not replying for so long. On 16 December 2015 at 07:54, Ronny Pfannschmidt <opensou...@ronnypfannschmidt.de> wrote: Hello everyone, the talk about the sqlalchemy feature extra got me thinking what if i could specify extras that

[Distutils] Idea: Positive/negative extras in general and as replacement for features

Hello everyone, the talk about the sqlalchemy feature extra got me thinking what if i could specify extras that where installed by default, but users could opt out a concrete example i have in mind is the default set of pytest plugins i would like to be able to externalize legacy support

Re: [Distutils] setup.py install using pip

cost additional maintenance on setuptools. Please keep in mind, that setuptools is completely on volunteer time, and the time given to it is scarce. Am 7. Dezember 2015 05:36:42 MEZ, schrieb Nick Coghlan <ncogh...@gmail.com>: >On 4 December 2015 at 17:55, Ronny Pfannschmidt

Re: [Distutils] setup.py install using pip

But it still needs a change in command A direct switch to a real pip command comes with a free implementation and zero additional features to maintain in setuptools Am 3. Dezember 2015 23:01:21 MEZ, schrieb Erik Bray <erik.m.b...@gmail.com>: >On Thu, Dec 3, 2015 at 3:37 PM, Ronny Pfa

Re: [Distutils] setup.py install using pip

Lets avoid getting setuptools even more complex in that way Putting pip-ish-ness on top of easy install is a maintenance horror and I don't think setuptools does has enough consistent developer resources to handle something like that Instead let's just give options to destroy the normal

Re: [Distutils] build system abstraction PEP, take #2

if pip has ways for them to avoid platform pitfalls like exe files Am 17. November 2015 08:15:41 MEZ, schrieb Robert Collins <robe...@robertcollins.net>: >On 17 November 2015 at 19:16, Ronny Pfannschmidt ><opensou...@ronnypfannschmidt.de> wrote: >> The develop command sh

Re: [Distutils] Why github and bitbucket?

I'm slowly working on something to transfer the issues, then it might be feasible to move things into one place as people agree. However currently I'm without a personal PC, so no open source work for me -- Ronny Am 5. November 2015 20:27:15 MEZ, schrieb "Thomas Güttler"

Re: [Distutils] Remove distutils, was: red, green, refactor ...

another example is that without a standard there is no viable way to replace a grown messy legacy tool with a much less messy tool over time creating a new trimmed down standard and supporting it from the legacy tool as well as from the new tool works out much better than trying to trim down the

Re: [Distutils] Time for a setuptools_lite??

why does that have to be in setuptools ?! if we want a new light system to begin with, shouldn't it be far more sustainable to use just implementations of the new standards rather than leaving all of setuptools there is no viable way in setuptools to get rid of the legacy ina sane and fast

Re: [Distutils] free project idea

my suggestion would be provide a whl_setup.py that works in a fashion similar to the current ez_setup however instead of using easy_install + eggs, it would use pip install --target into a folder relative to the setup.py that invoked it if there was a mechanism to prevent pip from invoking

Re: [Distutils] Time for a setuptools_lite??

to come up with useful tests -- Ronny On 10/21/2015 09:05 PM, Chris Barker wrote: > On Wed, Oct 21, 2015 at 10:03 AM, Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > why does that have to be in setuptoo

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I'd also like to join Am 9. Oktober 2015 06:29:58 MESZ, schrieb Robert Collins : >Toss me an invite too - I'm very interested in this, for all that I >havent' kibbitzed on the thread yet :) > >On 9 October 2015 at 05:33, Nathaniel Smith wrote: >> On

[Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)

Hi, i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push currently that would require various nasty hacks to get the version

Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)

On Wed, 2011-03-23 at 16:59 -0400, Mark Sienkiewicz wrote: Ronny Pfannschmidt wrote: Hi, i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible personally all i ever want to do to release a new version is:: $vcs

Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)

On Wed, 2011-03-23 at 22:47 +, Alexis Métaireau wrote: Le 23/03/2011 19:20, Ronny Pfannschmidt a écrit : Hi, Hey ronny ! i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible That's an usage a lot of people have

[Distutils] implementing egg-info/pkg_resources source support for custom importers

hi, I'm implementing a custom pep302 importer in order to ship sets of python packages within a generated python script, I'd like to support egg-info entry-points, so I can ship extensions as well as choose the script entry-point based on the executable name. However I couldn't find simple docs

[Distutils] whats the best way to depend on tools needed for setup.py/setup metadata

Hi, i'd like to support turning my guess version from hg metadata tool into a setup dependency and thus kill the need to ship a python file. Currently i just import it + call a function, but that doesn't exactly work if the module is missing and a dependency. Is there any way to turn it into

[Distutils] on storing vcs version infos in sdists

hi, whats a good place to store version information from a vcs in a sdist, without needing to drop them into python files. i wrote a simple module that gets me version meta-data from hg repos/archives, using the same algorithms hg is using for its own version number generation. The nit in that

Re: [Distutils] on storing vcs version infos in sdists

On Tue, 2010-05-25 at 13:09 -0400, P.J. Eby wrote: At 05:58 PM 5/25/2010 +0200, Ronny Pfannschmidt wrote: hi, whats a good place to store version information from a vcs in a sdist, without needing to drop them into python files. i wrote a simple module that gets me version meta-data from

Re: [Distutils] Distribute 0.6.12 broken on Windows

On Thu, 2010-05-20 at 14:09 -0700, Sridhar Ratnakumar wrote: On 5/19/2010 3:47 PM, Ronny Pfannschmidt wrote: On Wed, 2010-05-19 at 15:10 -0700, Sridhar Ratnakumar wrote: On 2010-05-19, at 2:53 PM, Sridhar Ratnakumar wrote: Ronny has fixed the .local / ENABLE_USER_SITE flag if you

Re: [Distutils] refining the idea of entrypoints and their metadata

On Tue, 2010-01-12 at 01:28 -0500, P.J. Eby wrote: At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote: Hi, while toying with the entrypoint system, i repeatedly ran into the need of having additional metadata prior to importing In Plugins that only handle certain filetypes/extensions

[Distutils] refining the idea of entrypoints and their metadata

Hi, while toying with the entrypoint system, i repeatedly ran into the need of having additional metadata prior to importing In Plugins that only handle certain filetypes/extensions/mimetypes might profit from the additional metadata (while also defering imports) The same goes for my library

Re: [Distutils] RFC822, PKG-INFO and the Description field

On Sat, 2009-12-05 at 03:49 +0100, Tarek Ziadé wrote: Hi, I am currently fixing a bug in Distutils: http://bugs.python.org/issue1923 this bugs makes a Description field like: Text:: a literal python block:: import this Transformed into : Text:: a literal

[Distutils] specifying the shipping of subpackages without their superpackages

Hi, i recently noticed that shipping a package like 'foo.bar' without also shipping 'foo' seems to work fine in distutils. since that would be nice way to ship packages within a namespace i want to sugest specifying the fact that it works and to clarify how it works. Regards Ronny

Re: [Distutils] specifying the shipping of subpackages without their superpackages

On Tue, 2009-11-24 at 13:03 +, Chris Withers wrote: Ronny Pfannschmidt wrote: i recently noticed that shipping a package like 'foo.bar' without also shipping 'foo' seems to work fine in distutils. since that would be nice way to ship packages within a namespace i want to sugest