Re: [openstack-dev] [all] [glance] python namespaces considered harmful to development, lets not introduce more of them

amespace packages should work without those problems, but you know, Python 3 only. Generally it’s my opinion that ``import foo_bar`` isn’t particularly any better or worse than ``import foo.bar``. The only real benefit is being able to iterate over ``foo.*``, however I’d just recommend using

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

I don't know the specific situation but it's appropriate to do this if you're using requests and wish to interact with the urllib3 that requests is using. > On Sep 17, 2014, at 11:15 AM, Thomas Goirand wrote: > > Hi, > > I'm horrified by what I just found. I have just found out this in > glanc

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Looking at the code on my phone it looks completely correct to use the vendored copy here and it wouldn't actually work otherwise. > On Sep 17, 2014, at 11:17 AM, Donald Stufft wrote: > > I don't know the specific situation but it's appropriate to do this if you'

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

e, and never use > the embedded version. Generally you either work with the embedded versions or you don’t use requests. You’re going to get very strange incompatibility problems if you try to mis requests.packages.urllib3 and urllib3 in one codebase and if you’re using requests at all it’s

Re: [openstack-dev] pbr alpha and dev version handling

_ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> ---

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

mpted this thread originally since the reason requests.packages.urllib3 was being imported from was so that there could be an is instance() check against one of the classes. If that wasn’t imported from requests.packages.urllib3 but instead from just urllib3 than the isinstance check would always

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

d. Our priority should be the end users. Distributions are not the only place that people get their software from, unless you think that the ~3 million downloads requests has received on PyPI in the last 30 days are distributions downloading requests to package in their OSs. --- Donald Stufft P

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 18, 2014, at 9:00 AM, Chmouel Boudjnah wrote: > > > On Thu, Sep 18, 2014 at 1:58 PM, Donald Stufft <mailto:don...@stufft.io>> wrote: > Distributions are not the only place that people get their software from, > unless you think that the ~3 million downloads

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

er of these options excludes the choice to lean on requests to reverse this decision as well. However that is best done elsewhere as the person making that decision isn't a member of these mailing lists as far as I am aware. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

unconditionally >> importing >> from the top level urllib3 for use within requests is flat out wrong. >> >> Obviously neither of these options excludes the choice to lean on requests to >> reverse this decision as well. However that is best done elsewhere as the >> person

Re: [openstack-dev] a "common" client library

win to me. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack

Re: [openstack-dev] a "common" client library

ased on an API specification (WADL could be used for >> that)? Not sure how convenient it would be, it really depends on a >> particular implementation, but as an idea it could be at least thought of. >> Sounds a little bit crazy though, I recognize it :). >> >> Renat Akhmero

Re: [openstack-dev] a "common" client library

be REST and/or Hypermedia. Things like WADL are completely antagonistic to actual REST (aka Hypermedia). --------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPG

Re: [openstack-dev] a "common" client library

Renat Akhmerov >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ > O

Re: [openstack-dev] a "common" client library

os and such ship with it disabled by default now IIRC. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev m

Re: [openstack-dev] a "common" client library

er one project will make it far easier to have a cohesive API amongst all the various services, it will reduce duplication of efforts, as well as make it easier to track security updates and I believe a wholly superior end user experience. - Donald Stufft PGP: 0x6E3CBCE93372DC

Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or straight to oslo.vmware

t > # http://julien.danjou.info > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D

Re: [openstack-dev] why do we put a license in every file?

It's nice when someone removes a file from the project. They get license information transmitted automatically without needing to do extra work. > On Feb 5, 2014, at 10:46 AM, Jay Pipes wrote: > >> On Wed, 2014-02-05 at 16:29 +, Greg Hill wrote: >> I'm new, so I'm sure there's some history

Re: [openstack-dev] olso.config error on running Devstack

Avoiding namespace packages is a good idea in general. At least until Python 3.whatever is baseline. > On Feb 5, 2014, at 10:58 AM, Doug Hellmann > wrote: > > > > >> On Wed, Feb 5, 2014 at 11:44 AM, Ben Nemec wrote: >>> On 2014-02-05 09:05, Doug Hellmann wrote: >>> >>> On Tue, Feb

Re: [openstack-dev] universal wheel support

compatible with the environment that is being installed into, it is not designed to restrict which environments a project supports. There is metadata for that in the new PEPs but nothing supports it yet. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6

Re: [openstack-dev] universal wheel support

On Feb 8, 2014, at 7:18 PM, Donald Stufft wrote: > Techincally you can upload a Wheel that supports any Python version, but I > don’t believe it’s exposed in the Wheel software at all. This is supposed to be “any Python2 version”. - Donald Stufft PGP: 0x6E3CBCE933

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

ower has a registry which maps names to git URLs and then the bower CLI looks up that mapping, fetches the git repository and then uses that as the input to the “look at metadata and do stuff with files” part of the package manager instead of the output of an un-unarchival command. -

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

> On Nov 21, 2014, at 11:32 AM, Jeremy Stanley wrote: > > On 2014-11-21 07:31:36 -0500 (-0500), Donald Stufft wrote: >> You can’t. Bower doesn’t have “traditional” packages where you take a >> directory and archive it using tar/zip/whatever and then upload it to >

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

> On Nov 21, 2014, at 11:57 AM, Jeremy Stanley wrote: > > On 2014-11-21 11:39:00 -0500 (-0500), Donald Stufft wrote: >> Well it’s a git repository, so you could just clone it and look at >> it. > > Aha, your earlier description made it sound like Bower was a file &g

Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

y team to comment on >> the patch? > > The discussion in https://launchpad.net/bugs/1381365 is relevant to > this topic. > -- > Jeremy Stanley > Death to SSLv3 IMO. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

> On Nov 22, 2014, at 1:45 AM, Robert Collins wrote: > > On 22 November 2014 08:11, Jeremy Stanley wrote: >> On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote: >>> Death to SSLv3 IMO. >> >> Sure, we should avoid releasing new versions of things whic

Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

> >> On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote: >> Yes this. SSLv3 isn’t a “Well as long as you have newer things >> enabled it’s fine” it’s a “If you have this enabled at all it’s a >> problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM &g

Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

uses a secure option when both a secure and an insecure option exist. http://crypto.stackexchange.com/a/10496 > On Nov 22, 2014, at 4:13 PM, Donald Stufft wrote: > > I'm in my phone but rfc 2246 says that there are many ways in which an > attacker can attempt to make an atta

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

d or rewrite nova in eventlet. > > The main 'winning' answer came down to twisted being very opaque for new > devs - while it's very powerful for experienced devs, we decided to opt > for eventlet which does not scare new devs with a completely different > progra

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

ramming because I won’t get an implicit context switch in the middle of a function. Compare that to the implicit async where the failure mode is that at runtime something weird happens. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

live up to the “gets out of my way-ness” of the abstractions you’re citing I’d personally much rather pass on it. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org htt

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

> On Nov 23, 2014, at 7:55 PM, Mike Bayer wrote: > >> >> On Nov 23, 2014, at 7:30 PM, Donald Stufft wrote: >> >> >>> On Nov 23, 2014, at 7:21 PM, Mike Bayer wrote: >>> >>> Given that, I’ve yet to understand why a system that im

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

> On Nov 23, 2014, at 9:09 PM, Mike Bayer wrote: > > >> On Nov 23, 2014, at 8:23 PM, Donald Stufft wrote: >> >> I don’t really take performance issues that seriously for CPython. If you >> care about performance you should be using PyPy. I like that arg

Re: [openstack-dev] suds-jurko, new in our global-requirements.txt: what is the point?!?

wonder, what is the point of using suds-jurko, which is half-baked, > and which will conflict with the suds package? > It looks like it uses 2to3 to become Python 3 compatible. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [openstack-dev] oslo.db 1.3.0 released

e juno. > > http://logs.openstack.org/07/137307/1/gate//gate-grenade-dsvm/048ee63//logs/old/screen-s-proxy.txt.gz > > pkg_resources.VersionConflict: SQLAlchemy 0.8.4 is installed but > SQLAlchemy>=0.9.7,<=0.9.99 is required by ['oslo.db'] > > -Sean It should pr

Re: [openstack-dev] oslo.db 1.3.0 released

> On Dec 15, 2014, at 1:57 PM, Sean Dague wrote: > > On 12/15/2014 01:53 PM, Donald Stufft wrote: >> >>> On Dec 15, 2014, at 1:50 PM, Sean Dague wrote: >>> >>> On 12/15/2014 12:01 PM, Jeremy Stanley wrote: >>>> On 2014-12-15 11:53:07 -05

Re: [openstack-dev] [oslo] versioning and releases

o include pre-releases so stuff like >=1.2a0,<1.3 would include 1.2a0 and higher, and “less than 1.3”. Unfortunately that’s a bit wonky still because 1.3a0 is technically < 1.3 so it’d match too. At least until we finish implementing PEP 440. - Donald Stufft PGP: 0x6E3CBCE933

Re: [openstack-dev] Pecan Evaluation for Marconi

t the other project is doing in place of a dependency for the feature(s) that depend on them (which the answer may be that it doesn’t have that feature, and then you have to decide if that feature is useful to you and if you’ll need to add a dependency or write less battle tested code in o

Re: [openstack-dev] Issues with Python Requests

; [1] > http://docs.python-requests.org/en/latest/user/advanced/#blocking-or-non-blocking > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - Donald Stufft PGP: 0x6E3CBCE93372DC

Re: [openstack-dev] Issues with Python Requests

On Apr 4, 2014, at 10:56 AM, Chuck Thier wrote: > On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote: > requests should work fine if you used the event let monkey patch the socket > module prior to import requests. > > That's what I had hoped as well (and is what swi

Re: [openstack-dev] [oslo] use of the "oslo" namespace package

ally, it might end up being so unworkable we would need > to switch. > > Mark. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev P

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

class? Ironically reimplementing that is probably more dangerous for security than requests bundling urllib3 ;) --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 19, 2014, at 12:42 PM, Mark Washenberger > wrote: > > > > On Fri, Sep 19, 2014 at 8:59 AM, Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Sep 19, 2014, at 11:54 AM, Brant Knudson > <mailto:b...@acm.org>> wrote: >>

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 19, 2014, at 2:26 PM, Chmouel Boudjnah wrote: > > > On Fri, Sep 19, 2014 at 6:58 PM, Donald Stufft <mailto:don...@stufft.io>> wrote: > So you can remove all that code and just let requests/urllib3 handle it on > 3.2+, 2.7.9+ and for anything less than

Re: [openstack-dev] Cross distribution talks on Friday

> Perhaps we need a top level Python Version library, not Oslo? Is there such > a thing? Seems like it should not be something specific to OpenStack What does pbr.version do? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] dropping namespace packages

ribution and git repository both will be called > “oslo.foo” and the import statement would look like “from oslo_foo import > bar”. > > Doug > > [1] https://etherpad.openstack.org/p/kilo-oslo-namespace-packages > [2] https://review.openstack.org/128759 +1 for whatever my vo

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

is that Doug Crockford gave Eclipse a license to his software without that line, and eclipse is sharing it so jshint is going to rebase off of the “Crockford” version and onto the Eclipse version. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

from my view point. What's > painful is to link an existing xstatic package with an already existing > libjs-* package that may have a completely different directory > structure. You can then end-up with a forest of symlinks, but there's no > way around that. No wrappe

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

> On Nov 13, 2014, at 5:23 PM, Thomas Goirand wrote: > > On 11/14/2014 02:11 AM, Donald Stufft wrote: >>> On Nov 13, 2014, at 12:38 PM, Thomas Goirand wrote: >>> On 11/13/2014 10:56 PM, Martin Geisler wrote: >>>> However, the whole JavaScript ecosystem se

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

> On Nov 14, 2014, at 7:48 AM, Matthias Runge wrote: > > On 13/11/14 19:11, Donald Stufft wrote: > >> As far as I’m aware npm supports TLS the same as pip does. That secures the >> transport between the end users and the repository so you can be assured >> that

Re: [openstack-dev] improving PyPi modules design & FHS (was: the future of angularjs development in Horizon)

> On Nov 13, 2014, at 6:29 PM, Thomas Goirand wrote: > > On 11/14/2014 06:40 AM, Donald Stufft wrote: >>>>> Sure! That's how I do most of my Python modules these days. I don't just >>>>> create them from scratch, I use my own "debpypi"

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

> On Nov 14, 2014, at 1:57 PM, Thomas Goirand wrote: > > On 11/14/2014 08:48 PM, Matthias Runge wrote: >> On 13/11/14 19:11, Donald Stufft wrote: >> >>> As far as I’m aware npm supports TLS the same as pip does. That secures the >>> transport between the

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

dicated IP addresses with them so we can provide them with whatever certificate we want, now it’s just a matter of selecting CAs and the political process. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing li

Re: [openstack-dev] [oslo] Adopting pylockfile

t we might be able to >> decouple it like oslo.db did. I think that would be messy though >> because Windows is where problems would come up and we don't test >> Windows in the gate. :-/ >> >>> >>>> Doug >>> >>> >>>>>> &

Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?

hen fall back to to >>> pypi.python.org >>>>>>>> <http://pypi.python.org/>. I think the only real solution is what >>>>>>>> Angus mentioned, remove yourself from projects.txt at least until >>> all >>>>>>>> your dependencies can be provi

Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?

ing devpi and pip caching would be that devpi > will allow you to install packages when you're offline. > > >Richard > > ___ > OpenStack-dev mailing list > OpenStack-dev@lis

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

the release number and being 2.25.0.8 or so. That’s mostly just a semantic thing (except for >) not any functional reason. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA __ OpenStack Develop

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

world, would any one >> really trust the data after migrating downwards? > > I do not think downward migrations are a good idea. I think they are a > spectacularly bad idea that is essentially designed to get users into a > state where they are massively broken. > > Oper

Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

"dep2", ], }, ) Then if you do ``pip install myproject[somename]`` it'll include dep1 and dep2 in the list of dependencies, you can also depend on this in other projects like: setup( install_requires=["myproject[somename]>

Re: [openstack-dev] [Glance][Artifacts] Object Version format: SemVer vs pep440

work with versions, and the additional PEPs or other documentations would be written on top of PEP 440 to add opinions on what a version looks like within the framework that PEP 440 sets up. A great example is the pbr semver document that Monty linked. --- D

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

I don't personally get too bothered by it but it feels like maybe the fundamental issue that some are expericing is when there are decisions being made via a single channel, regardless of if that channel is a phone call, IRC, a mailing list, or a design summit. The more channels any particu

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

ould contain the pinned set, and eventually the pinned >> set including transitive dependencies. >> >> Thoughts? > > I'm interested in seeing what that list looks like. I suspect we have > some libraries listed in the global requirements now that aren't

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

> On Feb 18, 2015, at 10:14 AM, Doug Hellmann wrote: > > > > On Wed, Feb 18, 2015, at 10:07 AM, Donald Stufft wrote: >> >>> On Feb 18, 2015, at 10:00 AM, Doug Hellmann wrote: >>> >>> >>> >>> On Tue, Feb 17, 2015, at 03:1

Re: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package

>> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.o

Re: [openstack-dev] [oslo][pbr] fixing up pbr's master branch

are completely supported, the only thing we changed is which one was the canonical representation. Other than that using one is equivalent to using the other. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using

Re: [openstack-dev] [all][pbr] splitting our deployment vs install dependencies

> On Apr 15, 2015, at 5:06 AM, Thierry Carrez wrote: > > Joe Gordon wrote: >> On Tue, Apr 14, 2015 at 2:55 PM, Chris Dent > > wrote: >>On Tue, 14 Apr 2015, Joe Gordon wrote: >>deploy requirements - requirements.txt - which are meant to >>be