; is this the desired behaviour?
>
The extra-paths egg recipe option should work, regardless of whether the
interpreter option is used.
Please create an issue:
https://github.com/buildout/buildout/issues/new
and include a full configuration file that demonstrates the problem so we
the same
> build environment?
>
I'm a huge fan of isolation, but isolation seems to me to be orthogonal to
this discussion.
I'm done with this thread. :)
Jim
>
> 2017-08-22 10:23 GMT-05:00 Jim Fulton :
>
>> I didn't mention (nor do I recall anyone mentioning) venvs.
I didn't mention (nor do I recall anyone mentioning) venvs.
Jim
On Tue, Aug 22, 2017 at 11:15 AM, Matt Joyce wrote:
> venvs within venvs... terrifying concept.
>
> On Tue, Aug 22, 2017 at 11:02 AM, Jim Fulton wrote:
>
>>
>>
>> On Tue, Aug 22, 2017 at 9:23 AM
ng I'd love to see go
away.
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ldout could have coped (eventually).
Jim
> 2017-08-21 16:27 GMT-05:00 Jim Fulton :
>
>>
>>
>> On Mon, Aug 21, 2017 at 5:17 PM, xoviat wrote:
>>
>>> Of course, to be frank, the principle failure with this plan is that
>>> third-party tools (buildou
ference build backend for setuptools: simply
>> copy the files and dist-info into a new compliant zip archive
>>
>> Viola! Setuptools is no longer required to build setuptools, and the
>> installation process is fully compliant with Python PEPs.
>>
>
>
>
On Sun, Apr 2, 2017 at 1:29 PM, Donald Stufft wrote:
>
> On Apr 2, 2017, at 1:24 PM, Jim Fulton wrote:
>
>
>
> Can you post this on https://github.com/pypa/setuptools/issues/980? That’s
> where most of the discussion from the fall out of setuptools devendoring
> has co
dencies of packages being managed.
IDK what the answer is. I'm just (re-)raising the issue and providing a
data point. I suspect that packaging tools should manage their own
dependencies independently. That's what was happening until recently IIUC
for the pypa tools through vendoring. I did
The old horrible doctest-based buildout documentation has finally been
replaced:
http://docs.buildout.org
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo
r.
>
Thank you!
...
I do intend to reuse some of the work done by Robert Collins in PR #2716 on
> pip's GitHub repository.
>
Are you aware of the proof of concept in distlib?
https://distil.readthedocs.io/en/0.1.0/overview.html#actual-improvements
Jim
--
Jim
malised names throughout might help
> such tools.
>
Thanks Paul. Yes, this is a buildout bug:
https://github.com/buildout/buildout/issues/317
This case shed the light on the bug for me. Thanks.
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
en
> maintainers don't update their pinned requirements.
>
I suppose this isn't a problem for Java applications, which use jar files
and per-application class paths.
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillis
most said competition) between pip and
buildout. They provide two different models (traditional Python system
installs vs Java-like component/path installs) that address different use
cases. IMO, these systems should complement each other and build on common
foundations.
Maybe there are more c
for setuptools for a while (yeah, I know, the
warts, really, I know) because I really don't think there's a desire to
innovate or a reason for competition at this level. In the case of wheel,
perhaps it makes sense for that implementation to be authoritative.
Thanks.
Jim
-
ta and
makes it impossible for buildout to install python-dateutil from a wheel.)
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Tue, Jan 17, 2017 at 11:34 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
>
>
> Am 16.01.2017 um 18:06 schrieb Jim Fulton:
>
>>
>>
>> On Mon, Jan 16, 2017 at 11:03 AM, Thomas Güttler <
>> guettl...@thomas-guettler.de &l
On Mon, Jan 16, 2017 at 11:03 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
>
>
> Am 13.01.2017 um 16:25 schrieb Jim Fulton:
>
>>
>>
>> On Fri, Jan 13, 2017 at 7:23 AM, Thomas Güttler <
>> guettl...@thomas-guettler.de <mailto:guettl...@
ction, so systems
typically pin all of their dependencies, ideally extending to their
environments (which is a reason why container technology is attractive).
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.
Gaaa, I should have stayed mum. Missed referring to the develop egg
too, as Leonardo pointed out.
Thanks.
Jim
On Tue, Sep 13, 2016 at 5:18 PM, Fred Drake wrote:
> On Tue, Sep 13, 2016 at 4:44 PM, Jim Fulton wrote:
>> You're missing:
>>
>>develop .
>>
django
>ipython
>django_extensions
> project-name = mytest
You're missing:
develop .
to have buildout create and include a develop egg using the current
directory with it's dependencies.
Jim
--
Jim Fulton
http://jimfulton.info
__
On Sun, Aug 21, 2016 at 12:29 PM, Donald Stufft wrote:
>
> On Aug 21, 2016, at 12:19 PM, Jim Fulton wrote:
>
> I'm open to shelling out, but pessimistic that it will turn out well. I
> started with that approach initially with easy_install and it fell apart
> quickly.
I
started with that approach initially with easy_install and it fell apart
quickly. But when we get into it... who knows?
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/list
On Sat, Aug 20, 2016 at 11:07 PM, Nick Coghlan wrote:
> On 21 August 2016 at 05:46, Jim Fulton wrote:
> > On Sat, Aug 20, 2016 at 3:02 PM, Nick Coghlan
> wrote:
> >> > I have the impression that uninstalling things can be
> >> > prob
t;
So, if package A and B install the same file, X, and then A is uninstalled,
is X still there? If then B is uninstalled, does X go away? Does this
machinery depend on whether X has the the same contents in A and B?
...
Jim
--
Jim Fulton
http://jimfulton.info
___
iderations.
In the long run, I suspect it would be best for some buildout developers to
offer pip PRs that abstract functionality into libraries that buildout
could call (and that pip called internally), although it sounds like this
may already be happening without our help.
Jim
--
Jim
itself without modifying the Python install, although I still
rather like that feature.
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
possibly with some sort of review) has
> some of the security shaped footguns as well as a problem with deciding who
> to trust with a name or not.
>
> —
> Donald Stufft
>
>
>
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman
ents,
> failing that mark it as "possibly out of date"
I'm curious why you view this as a problem that needs to be solved?
- Do you want to take over the name yourself?
- Are you afraid someone will stumble on this package and use it?
Something else?
Jim
--
Jim Fulton
http:/
On Thu, Jun 16, 2016 at 8:47 PM, Nick Coghlan wrote:
> On 16 June 2016 at 05:01, Jim Fulton wrote:
>> I'm a fan of docker, but it seems to me that build workflow is a an
>> unsolved problem if you need build tools that you don't want be
>> included at run time
On Wed, Jun 15, 2016 at 5:39 PM, Reinout van Rees wrote:
> Op 15-06-16 om 13:53 schreef Jim Fulton:
>>
>>
>> 1. Creating production docker images works best when all you're doing
>> is installing a bunch of binary artifacts (e.g. .debs, eggs, wheels).
>
>
On Wed, Jun 15, 2016 at 7:57 AM, Donald Stufft wrote:
>
>> On Jun 15, 2016, at 7:53 AM, Jim Fulton wrote:
>>
>> If you actually build programs as part of image building, then your
>> image contains build tools, leading to image bloat and potentially
>> security
log into and do development in. Emacs
makes this easy for me and provides all the development capabilities I
normally use, so this setup works well for me, but probably doesn't
work for non-emacs users. :) )
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
for a README file just doesn't
> seem such a big deal that alienating potential community members is
> worth it.
Which begs the question, which dialect of Markdown are you suggesting
we support. :)
Jim
--
Jim Fulton
http://jimfulton.info
___
On Mon, Apr 25, 2016 at 2:45 PM, Jim Fulton wrote:
> Due to recent changes in PyPI URLs. This breaks buildout's
> bootstrap.py as well as other tools.
I created an PR against the setuptools repo that should fix this.
Jim
--
Jim Fulton
http://jim
Due to recent changes in PyPI URLs. This breaks buildout's
bootstrap.py as well as other tools.
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
and will again, more and more.
>
> -CHB
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
?
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
See issue
> https://github.com/buildout/buildout/issues/249 .
You can make a bootstrap release by merging to the bootstrap_release branch.
I can make releases this weekend, or I can empower you. Which would you prefer?
Jim
--
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
yPI a sort of historical archive then perhaps we
> could have a feature to select 'supported' versions by the author, and
> allow a query parameter to ask for all the versions.
You could simply limit the number of versions from PyPI
you consider.
Jim
--
Jim Fulton
http://www.li
r primary source of
> documentation though or if it's old documentation that they just can't
> delete.
I know I have documentation for at least one project hosted this way.
I don't remember how I set that up. :) I assume there will be some way
to notify owners of effecte
recipe has changed.
If a recipe is a develop egg, then it computes a hash for the recipe
based on it's
package contents.
A quick thing to try might be to hack _dir_hash to be a noop (e.g. add
``return 42`` at
the top and see if it makes the delay go a
, https://pypi.python.org/pypi/zc.rst2, which is a thin
but convenient wrapper around docutils for converting ReST
to various formats.)
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
me from a variety of places, including
setup.py, the versions section, and requirements stated in egg and
similar parts.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org
On Sat, Dec 27, 2014 at 1:47 PM, Alex Gaynor wrote:
> Jim Fulton zope.com> writes:
>
>>
>> Did someone forget to upload setuptools-8.4.zip?
>>
>> Jim
>>
>
>
> I don't really understand how it came about, but the sever was on the wrong
>
Bootstrapping buildout is failing because buildout uses
https://bootstrap.pypa.io/ez_setup.py
which tried to download:
https://pypi.python.org/packages/source/s/setuptools/setuptools-8.4.zip
which doesn't exist.
Did someone forget to upload setuptools-8.4.zip?
Jim
--
Jim Fulton
On Tue, Dec 16, 2014 at 11:48 AM, Donald Stufft wrote:
...
> Yea, I’m incredibly lucky to have found someone willing to pay me for my
> hobby. Rackspace pays me to work on Python packaging
Thanks Rackspace!
Jim
--
Jim Fulton
http://www.linkedin.com/in/jim
s setuptools <8.
This isn't a long-term, because old setuptools won't handle new-style
(better) versions.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.or
> versions.
>> RuntimeWarning,
>> >>>
>
> Ah, this is probably an issue with how I detected a legacy version and how
> setuptools parses a filename. I can probably get rid of the warning spam.
That's awesome, because with large download caches, there can be a lot
of spam, as in 2800 lines of spam for me. :)
I guess this is a good a time as any to clean up my cache.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Dec 15, 2014 at 7:05 PM, Maurits van Rees
wrote:
> Jim Fulton schreef op 15-12-14 19:15:
>>
>> Buildout doesn't try to merge dependency requirements from different
>> packages.
>> It just installs packages and their dependencies and builds up a wor
On Mon, Dec 15, 2014 at 1:45 PM, Donald Stufft wrote:
>
>> On Dec 15, 2014, at 1:27 PM, Jim Fulton wrote:
>>
>> I think the changes in version management in setuptools 8 are a great
>> step forward,
>> but I think the transition is going to hurt a lot.
>&
to
these changes.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
s up a working set.
It does merge constraints from the versions section (if any) with
whatever requirement
it's working on at any point in time.
I'm guessing that the requirement: zc.buildout==2.2.5,>=1.5.0
is coming from a setup spec or from some buildout section. It was a
valid spec once
but isn't any more.
Buildout 2 before 2.3 did a lot of strange gymnastics to try to merge
version constraints
with requirement specs given the strange old rules.
Now, with the new sane rules, it just adds the constraint to the
whatever existing spec is
in the requirement.
There error "Bad constraint 2.0.5 five.localsitemanager>2.0dev" looks
to me like a bug. :)
When buildout gets a single-version constraint, like 2.0.5, it tests
whether that version
is "in" (__contains__) a requirement.
>>> import pkg_resources
>>> r = pkg_resources.Requirement.parse("five.localsitemanager>2.0dev")
>>> '2.0.5' in r
False
>>> r = pkg_resources.Requirement.parse("five.localsitemanager>2.0.dev0")
>>> '2.0.5' in r
True
I have a feeling the definition of "dev" has changed too.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
This fixes some compatibility issues with (and requires) setuptools 8.
The bootstrap file has been fixed and also moved to a more secure location:
https://bootstrap.pypa.io/bootstrap-buildout.py
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
t. My guess is that adding discovery of wheels in indexes and
such probably isn't that hard.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Wed, Dec 3, 2014 at 10:12 AM, Paul Moore wrote:
> On 3 December 2014 at 14:47, Jim Fulton wrote:
>>> Am I missing something about binary support with wheels?
>>
>> I don't think so.
>
> Agreed.
>
> It seems to me that the key issue currently is
On Wed, Dec 3, 2014 at 9:32 AM, Randy Syring wrote:
>
> On 12/03/2014 09:01 AM, Jim Fulton wrote:
>
> Many users, like myself, download source releases exclusively, and
> to us, wheels are irrelevent. However, users on Windows or who use
> systems without build tools for
On Wed, Dec 3, 2014 at 9:12 AM, Donald Stufft wrote:
>
>> On Dec 3, 2014, at 9:01 AM, Jim Fulton wrote:
>>
>> - Implementing and maintaining packaging code isn't really all that
>> interesting to me and, I'd hazard to guess, to anyone else on the
>>
I use every day
to go years without change.
I realize that activity is an easy metric, especially when
looking at projects with which you aren't familiar. I often use
it myself, but it's important to keep it's limitations in mind.
--
Jim Fulton
http://www.link
On Tue, Dec 2, 2014 at 7:53 AM, Reinout van Rees wrote:
> On 01-12-14 14:55, Piotr Dobrogost wrote:
>>
>> Are there any plans to move from easy_install/eggs to pip/wheels in
>> buildout?
>
>
> I asked that too, once. I think Jim Fulton said that there was a mismatch
n a
> per-distribution directory (i.e. allowing multiple versions of the same
> wheel to coexist).
Yes. Effectively eggs.
> These directories would be then added to sys.path in the
> script wrappers like buildout usually does.
Yu
s that pip uses and that other tools can
use.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Sun, Sep 28, 2014 at 3:31 PM, Donald Stufft
wrote:
> Hello All!
>
> I'd like to discuss the idea of moving PyPI to having immutable files.
...
+1
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist -
as root.
Unfortunately, our current scheme is working well enough and we have
enough other priorities that I fear I won't find time to dockerfy our
processes soon.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Sep 8, 2014 at 11:31 AM, Piotr Dobrogost
wrote:
> On Mon, Sep 8, 2014 at 3:46 PM, Jim Fulton wrote:
>>
>> This is why I *always* use a clean python built from source.
>> I recommend people do the same, or use a virtualenv.
>
> Well, I read http://www.
On Mon, Sep 8, 2014 at 7:44 AM, Piotr Dobrogost
wrote:
> Jim, thanks for taking time to reply.
>
> On Sun, Sep 7, 2014 at 4:09 PM, Jim Fulton wrote:
>>
>> Wow. That's really old and not really supported any more.
>>
>> It also uses very old
> something else? If it uses easy_install is there any way to pass
> options to easy_install used?
Buildout uses setuptools, which is what easy_install uses. (Buildout originally
used easy_install more or less directly and still does in some narrow cases.)
Please upgrade to buildout 2.
er image or
> just directly on a VM. It's all very alpha but I'm using it successfully
> with ansible to distribute tarballs to VMs in production.
>
> [1] https://github.com/mmerickel/marina
Not sure I follow all the above, but it sounds intere
s, might come close:
https://bitbucket.org/zc/packagegrinder
I'm really hoping that Docker will eventually allow us to stop
building system packages though.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
loyed, as this is mostly done
when building an image. The isolation provided by docker containers
also allows configuration to be simpler. There's still benefit of having
a system like buildout with Python recipes to automate assembly
(often including non-python bits like JavaScript libraries) and
s://bitbucket.org/zc/zrs-rpm/src
Note the buildout.cfg and spec file.
Also note that my philosophy is that RPMs should contain
software, not configuration. We configure processes and
such separately from building RPMs. We use buildout
to build run-time configurations. :)
Of course, Docker
I've posted a new buildout 2 and 2.1 bootstrap script:
http://downloads.buildout.org/2/bootstrap.py
That has the new location of the ez_setup.py script.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG mai
ng & Python Consulting
>- http://www.simplistix.co.uk
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
t as a default.
I'll give this some thought, but some possible ideas:
- Provide an option to install the eggs for a part in a single
directory.
collective.recipe.omlette does this, although it doesn't seem to be
used for run-time package lookup afaict from the docs. You might
sitories with a lot
> of subcomponents?
Checkout Buildout, http://www.buildout.org
It addresses a lot of the same problems. Of course, for Python, compiling is
(mostly) not all that important. For us (Zope Corporation) buildout
is more about
assembly/deployment, both for development and pr
ckage typically has:
import pkg_resources
pkg_resources.declare_namespace(__name__)
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Tue, Feb 18, 2014 at 6:41 AM, Eric V. Smith wrote:
> On 2/17/2014 6:13 AM, Jim Fulton wrote:
>> On Sun, Feb 16, 2014 at 10:46 PM, Eric V. Smith wrote:
>>> In older versions of bootstrap.py, the --setup-source option would let
>>> me select an alternate source of ez_
internet access. The requirement for internet
> access breaks this setup.
>
> Is there some reason --setup-source was removed?
I didn't know people needed it and was trying to reduce the complexity
of the bootstrap source. We can add it back,
Jim
--
J
ird.
You can control the index URL using the buildout index option.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
the future we'll to docker or maybe something simpler
than RPM, which doesn't really match our use cases very well and tends
to cause us no end of pain.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Thu, Oct 17, 2013 at 11:26 AM, Donald Stufft wrote:
>
> On Oct 17, 2013, at 11:23 AM, Jim Fulton wrote:
>
>> On Thu, Oct 17, 2013 at 11:20 AM, Michael Foord wrote:
>>>
>>>
>>>
>>> On 17 October 2013 11:56, Donald Stufft wrote:
>>>&
its way more user
>> friendly to tell them up front then to confuse them when it doesn't work or
>> when it appears to work but they get an error from a -
>>
>
> You're proposing replacing "arguably broken" (by some definition)
Is there any reason to think
distributions. The only
breakage would be for authors uploading the buggy distributions. These
are the people who could actually address the breakage and who would benefit
from the breakage by finding out that they have a bug in their distributions.
This seems an appropriate form of br
On Tue, Oct 15, 2013 at 10:27 AM, Adam GROSZER wrote:
> On 10/15/2013 03:38 PM, Jim Fulton wrote:
>>
>> On Tue, Oct 15, 2013 at 3:43 AM, Adam GROSZER
>> wrote:
>>>
>>> On 10/15/2013 12:14 AM, Alex Clark wrote:
>>>>
>>>>
>>>
out.org/1/bootstrap.py references that
> URL.
Is there a different URL that should be used? Or do you suggest dropping
distribute support from the buildout 1 bootstrap script?
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
onfidence in my understanding.
Did setuptools recently learn about git? For a while, an advantage of
git was that setuptools ignored it.
I would love an option to ignore VCS and let me specify what I
want *explicitly*.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
__
On Wed, Sep 4, 2013 at 9:08 AM, Antoine Pitrou wrote:
> Jim Fulton zope.com> writes:
>>
>> Some password managers (including both that I've used) let you access your
>> passwords via the web, so they aren't stored locally.
>
> Will they work with setup.p
On Wed, Sep 4, 2013 at 8:11 AM, Antoine Pitrou wrote:
> Jim Fulton zope.com> writes:
>>
>> People (at least technical people) should use password managers.
>
> I will gladly use a password manager on my personal computer, just *not*
> on a computer which other people
(at least technical people) should use password managers.
What annoys me is when a 40-character random password is rejected
because it doesn't contain a number (or a capitalized character letter
or whatever), when the same system would accept a 7-character
password. (It's easy enough
ORD file doesn't address that either.
Note that with multi-version support, uninstalling things is an optimization,
not a necessity. The only harm a never-uninstalled egg does is take up
space and maybe make tools that scan for what's installed take more time.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
pks_resources to do it.
(Buildout used pkg_resources at build time to manage package meta
data, but I think that's orthogonal to what you're talking about.)
I'd also hazard to guess that most of the folks with multi-version
installs are using build
m
* There was a well-intention but unfortunate deviation
in later buildout 1 versions. This was, somewhat ironically
in pursuit of better integration with system Python installations.
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
o
> go after. Prior to this push that was basically the only thing prevent
> someone from attacking people, that they had never decided to bother too. We
> are better, it's somewhat harder now, but in many areas that's still the
> only thing keeping people safe.
Well said.
S
://downloads.buildout.org/2/bootstrap.py
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
pport for multiple Python interpreters in a single buildout was
dropped from buildout 2.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
some other 0.6 version.
- Upgrade to buildout 2.1.1, which was just released. This will prevent
automatic upgrade to distribute 0.7 or buildout 2.2.
- Be prepared to re-bootstrap your buildouts with the the new buildout 2.2
bootstrap script, which will be released soon after the release of
distri
On Thu, Jun 20, 2013 at 11:06 AM, Sebastien Douche wrote:
> On Thu, Jun 20, 2013 at 4:37 PM, Jim Fulton wrote:
>> Testing has gone well, but I still anticipate a little excitement.
>
> Yeah. Maybe a good idea to wait Setuptools 0.8?
Why? It will pick up setuptools.8 when it be
Testing has gone well, but I still anticipate a little excitement.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
d for reviewing and merging a number of outstanding
pull requests. Of course, thanks to the folks to contributed the
many other changes in this release.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutil
staled.cfg.
> I've stumbled on this many times as well; I don't see an advantage to
> this not being handled by the bootstrap, because it will surprise us
> eventually.
It rarely surprises me.
> Some of us (include me, apparently) are more easily surprised than others.
No kiddin
you're forgoing cleanup.
It would be better to uninstall everything with the old buildout:
bin/buildout buildout:parts=
Before removing the installed file.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
1 - 100 of 825 matches
Mail list logo
