Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

zope.password

  

 
First page Previous page 1 2 Next page Last page  View All Zope dev RSS feed   Index | Next | Previous | View Threaded


dev at projekt01

Mar 9, 2009, 9:03 PM

Post #1 of 27 (2770 views)
Permalink
zope.password
Hi steering group and Dan

During update z3c.authenticator and replace the password with the
new zope.apssword implementation, I saw that the vocabulary
"Passsword Manager Names" is not available in the zope.password
package.

I think the password package should also provide this vocabulary.
Or at least the zope.app.authentication package should not
configure that.

Do you see any solution to solve that problem that not
both package zope.app.authentication and z3c.authenticator
configure that utility within the same name (needs the exclude
directive for make that working)

Regards
Roger Ineichen
_____________________________
END OF MESSAGE

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


nadako at gmail

Mar 10, 2009, 1:21 AM

Post #2 of 27 (2698 views)
Permalink
Re: zope.password [In reply to]
2009/3/10 Roger Ineichen <dev [at] projekt01>:
> Hi steering group and Dan
>
> During update z3c.authenticator and replace the password with the
> new zope.apssword implementation, I saw that the vocabulary
> "Passsword Manager Names" is not available in the zope.password
> package.
>
> I think the password package should also provide this vocabulary.
> Or at least the zope.app.authentication package should not
> configure that.
>
> Do you see any solution to solve that problem that not
> both package zope.app.authentication and z3c.authenticator
> configure that utility within the same name (needs the exclude
> directive for make that working)

This was done to avoid dependency on zope.schema. However, I also find
it very useful to have that vocabulary in zope.password. I think we
can add it to the "vocabulary" submodule without adding dependency on
zope.schema at egg level, because one who wants to use the vocabulary
probably already has zope.schema installed. I'll do that.

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


hannosch at hannosch

Mar 10, 2009, 2:24 AM

Post #3 of 27 (2703 views)
Permalink
Re: zope.password [In reply to]
Dan Korostelev wrote:
> This was done to avoid dependency on zope.schema. However, I also find
> it very useful to have that vocabulary in zope.password. I think we
> can add it to the "vocabulary" submodule without adding dependency on
> zope.schema at egg level, because one who wants to use the vocabulary
> probably already has zope.schema installed. I'll do that.

That reasoning sounds flawed to me.

Either you have a dependency and declare it or you don't have a
dependency. Since we don't want to use "extras" anymore, I think this
calls for another package which depends on zope.password and zope.schema.

Hanno

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


nadako at gmail

Mar 10, 2009, 3:53 AM

Post #4 of 27 (2699 views)
Permalink
Re: zope.password [In reply to]
2009/3/10 Hanno Schlichting <hannosch [at] hannosch>:
> Dan Korostelev wrote:
>> This was done to avoid dependency on zope.schema. However, I also find
>> it very useful to have that vocabulary in zope.password. I think we
>> can add it to the "vocabulary" submodule without adding dependency on
>> zope.schema at egg level, because one who wants to use the vocabulary
>> probably already has zope.schema installed. I'll do that.
>
> That reasoning sounds flawed to me.
>
> Either you have a dependency and declare it or you don't have a
> dependency. Since we don't want to use "extras" anymore, I think this
> calls for another package which depends on zope.password and zope.schema.

I still don't like/get the idea of creating and maintaining extra
package that merely contains a vocabulary factory for another package.
Whatever, I reverted that change. Roger, just exclude
zope.app.authentication's "password.zcml" file, include
"zope.password" explicitly and define your own vocabulary.

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


hannosch at hannosch

Mar 10, 2009, 4:00 AM

Post #5 of 27 (2704 views)
Permalink
Re: zope.password [In reply to]
Dan Korostelev wrote:
> 2009/3/10 Hanno Schlichting <hannosch [at] hannosch>:
>> Either you have a dependency and declare it or you don't have a
>> dependency. Since we don't want to use "extras" anymore, I think this
>> calls for another package which depends on zope.password and zope.schema.
>
> I still don't like/get the idea of creating and maintaining extra
> package that merely contains a vocabulary factory for another package.
> Whatever, I reverted that change. Roger, just exclude
> zope.app.authentication's "password.zcml" file, include
> "zope.password" explicitly and define your own vocabulary.

I don't quite like the idea of extras and we decided to avoid them. We
also decided to avoid tests_require from what I understand.

What you did was to not specify an extra nor a hard dependency, but
still add zope.schema to the test extra section.

That feels wrong. Either you have a dependency and so have the tests or
you don't.

I think extras have been created for this kind of use-case of providing
an "optional feature" from a package. Either we use that mechanism and
declare it, or we don't want this mechanism and live with creating extra
packages instead.

Hanno

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


dev at projekt01

Mar 10, 2009, 9:33 AM

Post #6 of 27 (2690 views)
Permalink
Re: zope.password [In reply to]
Hi Steering group, Hanno, Dan

> Betreff: Re: [Zope-dev] zope.password
>
> Dan Korostelev wrote:
> > 2009/3/10 Hanno Schlichting <hannosch [at] hannosch>:
> >> Either you have a dependency and declare it or you don't have a
> >> dependency. Since we don't want to use "extras" anymore, I
> think this
> >> calls for another package which depends on zope.password
> and zope.schema.
> >
> > I still don't like/get the idea of creating and maintaining extra
> > package that merely contains a vocabulary factory for
> another package.
> > Whatever, I reverted that change. Roger, just exclude
> > zope.app.authentication's "password.zcml" file, include
> > "zope.password" explicitly and define your own vocabulary.
>
> I don't quite like the idea of extras and we decided to avoid
> them. We also decided to avoid tests_require from what I understand.
>
> What you did was to not specify an extra nor a hard
> dependency, but still add zope.schema to the test extra section.
>
> That feels wrong. Either you have a dependency and so have
> the tests or you don't.
>
> I think extras have been created for this kind of use-case of
> providing an "optional feature" from a package. Either we use
> that mechanism and declare it, or we don't want this
> mechanism and live with creating extra packages instead.

Hanno,
Can you propose something else to solve our problem?

The problem is, zope.password offers password manager which get
used by zope.app.testing, zope.app.authentication, z3c.authenticator
and other packages. zope.app.authentication configures the vocabulary
for the password managers in zope.password.

That's defently a no go.

Write another package for just define and register them is
I think also a no go.

Probably we should depend zope.password on zope.schema too
and configure the vocabulary and managers registry there.

Dan,
I think we should not be to excessive with the dependency cleanup
and stop ourself. It would be nice to use zope.password without the
zope.schema package but that's right now no use case for our refactoring.

Steering group?


> Hanno
>
> _______________________________________________
> Zope-Dev maillist - Zope-Dev [at] zope
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


nadako at gmail

Mar 10, 2009, 10:17 AM

Post #7 of 27 (2688 views)
Permalink
Re: zope.password [In reply to]
2009/3/10 Roger Ineichen <dev [at] projekt01>:
> Hi Steering group, Hanno, Dan
>
>> Betreff: Re: [Zope-dev] zope.password
>>
>> Dan Korostelev wrote:
>> > 2009/3/10 Hanno Schlichting <hannosch [at] hannosch>:
>> >> Either you have a dependency and declare it or you don't have a
>> >> dependency. Since we don't want to use "extras" anymore, I
>> think this
>> >> calls for another package which depends on zope.password
>> and zope.schema.
>> >
>> > I still don't like/get the idea of creating and maintaining extra
>> > package that merely contains a vocabulary factory for
>> another package.
>> > Whatever, I reverted that change. Roger, just exclude
>> > zope.app.authentication's "password.zcml" file, include
>> > "zope.password" explicitly and define your own vocabulary.
>>
>> I don't quite like the idea of extras and we decided to avoid
>> them. We also decided to avoid tests_require from what I understand.
>>
>> What you did was to not specify an extra nor a hard
>> dependency, but still add zope.schema to the test extra section.
>>
>> That feels wrong. Either you have a dependency and so have
>> the tests or you don't.
>>
>> I think extras have been created for this kind of use-case of
>> providing an "optional feature" from a package. Either we use
>> that mechanism and declare it, or we don't want this
>> mechanism and live with creating extra packages instead.
>
> Hanno,
> Can you propose something else to solve our problem?
>
> The problem is, zope.password offers password manager which get
> used by zope.app.testing, zope.app.authentication, z3c.authenticator
> and other packages. zope.app.authentication configures the vocabulary
> for the password managers in zope.password.
>
> That's defently a no go.
>
> Write another package for just define and register them is
> I think also a no go.
>
> Probably we should depend zope.password on zope.schema too
> and configure the vocabulary and managers registry there.
>
> Dan,
> I think we should not be to excessive with the dependency cleanup
> and stop ourself. It would be nice to use zope.password without the
> zope.schema package but that's right now no use case for our refactoring.

I'd like to be able to use zope.password without zope.component for
some of my tiny old Pylons-based projects, that's why I'm trying to
avoid dependency on it. I believe that repoze guys will also be quite
happy, if it didn't pull unneeded (for them) dependency.

I'd be fine with an "extra" requirement, but others seem to be against that. :-/

Steering group? ;-)

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


srichter at cosmos

Mar 10, 2009, 10:19 AM

Post #8 of 27 (2701 views)
Permalink
Re: zope.password [In reply to]
On Tuesday 10 March 2009, Dan Korostelev wrote:
> > Either you have a dependency and declare it or you don't have a
> > dependency. Since we don't want to use "extras" anymore, I think this
> > calls for another package which depends on zope.password and zope.schema.
>
> I still don't like/get the idea of creating and maintaining extra
> package that merely contains a vocabulary factory for another package.
> Whatever, I reverted that change. Roger, just exclude
> zope.app.authentication's "password.zcml" file, include
> "zope.password" explicitly and define your own vocabulary.

I think we have become dependency paranoid. And we embrace package
proliferation instead, which in my opinion is equally bad. If you really hate
the dependency, make it an extra requires. I know that goes against the
latest guidelines as well...*sigh*

My big problem here is that we dismiss all solutions but new packages. We want
to minimize dependencies and not have extra includes. The only choice left is
a separate package. We should, however try to make the number of packages a
parameter too.

Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


dev at projekt01

Mar 10, 2009, 3:55 PM

Post #9 of 27 (2689 views)
Permalink
Re: zope.password [In reply to]
Hi Stephan

> Betreff: Re: [Zope-dev] zope.password
>
> On Tuesday 10 March 2009, Dan Korostelev wrote:
> > > Either you have a dependency and declare it or you don't have a
> > > dependency. Since we don't want to use "extras" anymore, I think
> > > this calls for another package which depends on
> zope.password and zope.schema.
> >
> > I still don't like/get the idea of creating and maintaining extra
> > package that merely contains a vocabulary factory for
> another package.
> > Whatever, I reverted that change. Roger, just exclude
> > zope.app.authentication's "password.zcml" file, include
> > "zope.password" explicitly and define your own vocabulary.
>
> I think we have become dependency paranoid. And we embrace
> package proliferation instead, which in my opinion is equally
> bad. If you really hate the dependency, make it an extra
> requires. I know that goes against the
> latest guidelines as well...*sigh*
>
> My big problem here is that we dismiss all solutions but new
> packages. We want to minimize dependencies and not have extra
> includes. The only choice left is a separate package. We
> should, however try to make the number of packages a parameter too.

This is exactly my reaction. It is allways bad to skip existing
patterns without to have a better one.

Note, there is always a reason for a pattern. We didn't just
develop that for fun. I think the steering group should think
about what are the consequence if we skip someting and how
we can solve the problems which get solved based on patterns
they like to skip.

Right now it means, skip extra_requires forces us to add more
new package and include them in the original package for BBB
reason which will add back the same dependency like we tried
to skip with extra_requires. But now as a hard depenency. ouch!

Regards
Roger Ineichen


> Regards,
> Stephan
> --
> Stephan Richter
> Web Software Design, Development and Training Google me.
> "Zope Stephan Richter"
>

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


dev at projekt01

Mar 10, 2009, 4:01 PM

Post #10 of 27 (2690 views)
Permalink
Re: zope.password [In reply to]
Hi Dan

> Betreff: Re: [Zope-dev] zope.password
>
> 2009/3/10 Roger Ineichen <dev [at] projekt01>:
> > Hi Steering group, Hanno, Dan
> >
> >> Betreff: Re: [Zope-dev] zope.password
> >>
> >> Dan Korostelev wrote:
> >> > 2009/3/10 Hanno Schlichting <hannosch [at] hannosch>:
> >> >> Either you have a dependency and declare it or you don't have a
> >> >> dependency. Since we don't want to use "extras" anymore, I
> >> think this
> >> >> calls for another package which depends on zope.password
> >> and zope.schema.
> >> >
> >> > I still don't like/get the idea of creating and
> maintaining extra
> >> > package that merely contains a vocabulary factory for
> >> another package.
> >> > Whatever, I reverted that change. Roger, just exclude
> >> > zope.app.authentication's "password.zcml" file, include
> >> > "zope.password" explicitly and define your own vocabulary.
> >>
> >> I don't quite like the idea of extras and we decided to
> avoid them.
> >> We also decided to avoid tests_require from what I understand.
> >>
> >> What you did was to not specify an extra nor a hard
> dependency, but
> >> still add zope.schema to the test extra section.
> >>
> >> That feels wrong. Either you have a dependency and so have
> the tests
> >> or you don't.
> >>
> >> I think extras have been created for this kind of use-case of
> >> providing an "optional feature" from a package. Either we use that
> >> mechanism and declare it, or we don't want this mechanism and live
> >> with creating extra packages instead.
> >
> > Hanno,
> > Can you propose something else to solve our problem?
> >
> > The problem is, zope.password offers password manager which
> get used
> > by zope.app.testing, zope.app.authentication, z3c.authenticator and
> > other packages. zope.app.authentication configures the
> vocabulary for
> > the password managers in zope.password.
> >
> > That's defently a no go.
> >
> > Write another package for just define and register them is I think
> > also a no go.
> >
> > Probably we should depend zope.password on zope.schema too and
> > configure the vocabulary and managers registry there.
> >
> > Dan,
> > I think we should not be to excessive with the dependency
> cleanup and
> > stop ourself. It would be nice to use zope.password without the
> > zope.schema package but that's right now no use case for
> our refactoring.
>
> I'd like to be able to use zope.password without
> zope.component for some of my tiny old Pylons-based projects,
> that's why I'm trying to avoid dependency on it. I believe
> that repoze guys will also be quite happy, if it didn't pull
> unneeded (for them) dependency.

I think that's a valid reason for your use case. But that's
a problem for the zope framework ;-)


> I'd be fine with an "extra" requirement, but others seem to
> be against that. :-/

I think we don't have any replacement pattern for extra_requires.
The extra_requires where developed for exactly that reason.
We should use that pattern till someone will show us a better
concept.

I also think to add an additional package for register a vocabulary
is very ugly.

Probably we should think about zope.app.security or something
like that and move the password managers and vocabulary to
someting like that.

Regards
Roger Ineichen

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Mar 11, 2009, 7:18 AM

Post #11 of 27 (2683 views)
Permalink
Re: zope.password [In reply to]
Hanno Schlichting wrote:
> Dan Korostelev wrote:
>> This was done to avoid dependency on zope.schema. However, I also find
>> it very useful to have that vocabulary in zope.password. I think we
>> can add it to the "vocabulary" submodule without adding dependency on
>> zope.schema at egg level, because one who wants to use the vocabulary
>> probably already has zope.schema installed. I'll do that.
>
> That reasoning sounds flawed to me.
>
> Either you have a dependency and declare it or you don't have a
> dependency. Since we don't want to use "extras" anymore, I think this
> calls for another package which depends on zope.password and zope.schema.

If zope.schema is imported from directly, it should be declared as a
dependency.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Mar 11, 2009, 7:19 AM

Post #12 of 27 (2686 views)
Permalink
Re: zope.password [In reply to]
Hey,

If it's more convenient to have the vocabulary available in
zope.password, by all means add it there.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Mar 11, 2009, 7:24 AM

Post #13 of 27 (2686 views)
Permalink
Re: zope.password [In reply to]
Hi there,

Okay, having read the whole thread, there seem to be two forces pulling
on zope.password:

* it'd be nice if zope.password had the vocabulary so that you didn't
have to include zope.app.authentication anymore just to get it.

* it'd be nice if zope.password didn't need any extra dependencies,
including zope.component and zope.schema.

I think the latter is the least important right now, especially since
zope.component and zope.schema are already very foundational libraries.
So just add the vocabulary to zope.password if that is the only new
dependencies it will pull in as a result.

In my opinion going for an extra here just to avoid this is speculating
a bit too much right now. Do we really have users that want to use
zope.password and really don't want zope.component and zope.schema? If
so, we'll hear from them when they speak up and *then* declare an extra
or take some other action.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


nadako at gmail

Mar 11, 2009, 8:05 AM

Post #14 of 27 (2686 views)
Permalink
Re: zope.password [In reply to]
2009/3/11 Martijn Faassen <faassen [at] startifact>:
> Hi there,
>
> Okay, having read the whole thread, there seem to be two forces pulling
> on zope.password:
>
> * it'd be nice if zope.password had the vocabulary so that you didn't
> have to include zope.app.authentication anymore just to get it.
>
> * it'd be nice if zope.password didn't need any extra dependencies,
> including zope.component and zope.schema.
>
> I think the latter is the least important right now, especially since
> zope.component and zope.schema are already very foundational libraries.
> So just add the vocabulary to zope.password if that is the only new
> dependencies it will pull in as a result.

I've moved the vocabulary to zope.password again, but I done the
"extra" for now, until the final decision will be made.

> In my opinion going for an extra here just to avoid this is speculating
> a bit too much right now. Do we really have users that want to use
> zope.password and really don't want zope.component and zope.schema? If
> so, we'll hear from them when they speak up and *then* declare an extra
> or take some other action.

Well, as I said before, I wanted to use zope.password in my old Pylons
application that only uses zope.interface currently. I don't expect it
to be developed in more zope-ish way (though I don't expect it to be
developed much in near future :)), so I'd like to avoid these
dependencies.

--
WBR, Dan Korostelev
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


srichter at cosmos

Mar 11, 2009, 8:33 AM

Post #15 of 27 (2681 views)
Permalink
Re: zope.password [In reply to]
On Wednesday 11 March 2009, Martijn Faassen wrote:
> I think the latter is the least important right now, especially since
> zope.component and zope.schema are already very foundational libraries.
> So just add the vocabulary to zope.password if that is the only new
> dependencies it will pull in as a result.
>
> In my opinion going for an extra here just to avoid this is speculating
> a bit too much right now. Do we really have users that want to use
> zope.password and really don't want zope.component and zope.schema? If
> so, we'll hear from them when they speak up and *then* declare an extra
> or take some other action.

+1. I want more of our decisions to go into this direction. It is a sign that
we turn the # of packages knob as well.

Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Mar 11, 2009, 9:17 AM

Post #16 of 27 (2680 views)
Permalink
Re: zope.password [In reply to]
Dan Korostelev wrote:
[snip]
> Well, as I said before, I wanted to use zope.password in my old Pylons
> application that only uses zope.interface currently. I don't expect it
> to be developed in more zope-ish way (though I don't expect it to be
> developed much in near future :)), so I'd like to avoid these
> dependencies.

Okay, thanks for the elaboration on this.

Let's try the extra for now then and see how it goes.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Mar 11, 2009, 9:27 AM

Post #17 of 27 (2677 views)
Permalink
Re: zope.password [In reply to]
Hi there,

Stephan Richter wrote:
[snip]
>> In my opinion going for an extra here just to avoid this is speculating
>> a bit too much right now. Do we really have users that want to use
>> zope.password and really don't want zope.component and zope.schema? If
>> so, we'll hear from them when they speak up and *then* declare an extra
>> or take some other action.
>
> +1. I want more of our decisions to go into this direction. It is a sign that
> we turn the # of packages knob as well.

I agree with you in the case against extras.

It appears though that Dan has a concrete use case for using
zope.password in a Pylons app where he isn't interested in
zope.component, so I'm +1 on the extra in this case. We'll see whether
this leads to difficulties. Luckily the zope.component and zope.schema
libraries are typically around anyway so it doesn't make reasoning about
the graph that much harder.

I'm just glad we actually had a quick discussion about this stuff, with
some form of conclusion.

On creating new packages, I think we're in a phase where we cannot avoid
creating new packages for a bit. Before long I hope that this generation
of more packages can allow us to seriously weed in the packages in the
framework. Zope 3 + ZMI will need a lot more packages for a while, but
anything that doesn't need the ZMI (Grok, Zope 2) will hopefully use a
lot less. In addition I hope more of our packages will be reusable
independently as a result.

I hope that some group will start to take care of Zope 3 and perhaps
consolidate a lot of ZMI code into one or more zmi.* packages eventually
too.

Besides the reusability argument and weeding argument for more packages,
I'll also note that if the amount of packages in the framework goes up
but the total amount of *code* in the framework goes down significantly
and each package is easier to understand, I'm happy to see the amount of
packages go up.

We'll see. We'll make some mistakes, undoubtedly, but at least we're
moving again. That is pretty important to me.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


tseaver at palladion

Mar 11, 2009, 2:35 PM

Post #18 of 27 (2674 views)
Permalink
Re: zope.password [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hi there,
>
> Stephan Richter wrote:
> [snip]
>>> In my opinion going for an extra here just to avoid this is speculating
>>> a bit too much right now. Do we really have users that want to use
>>> zope.password and really don't want zope.component and zope.schema? If
>>> so, we'll hear from them when they speak up and *then* declare an extra
>>> or take some other action.
>> +1. I want more of our decisions to go into this direction. It is a sign that
>> we turn the # of packages knob as well.
>
> I agree with you in the case against extras.
>
> It appears though that Dan has a concrete use case for using
> zope.password in a Pylons app where he isn't interested in
> zope.component, so I'm +1 on the extra in this case. We'll see whether
> this leads to difficulties. Luckily the zope.component and zope.schema
> libraries are typically around anyway so it doesn't make reasoning about
> the graph that much harder.
>
> I'm just glad we actually had a quick discussion about this stuff, with
> some form of conclusion.
>
> On creating new packages, I think we're in a phase where we cannot avoid
> creating new packages for a bit. Before long I hope that this generation
> of more packages can allow us to seriously weed in the packages in the
> framework. Zope 3 + ZMI will need a lot more packages for a while, but
> anything that doesn't need the ZMI (Grok, Zope 2) will hopefully use a
> lot less. In addition I hope more of our packages will be reusable
> independently as a result.

We should be trying to get all zope.app.* dependencies out of the Zope2
graph ASAP (before 2.12 final would be ideal).

> I hope that some group will start to take care of Zope 3 and perhaps
> consolidate a lot of ZMI code into one or more zmi.* packages eventually
> too.
>
> Besides the reusability argument and weeding argument for more packages,
> I'll also note that if the amount of packages in the framework goes up
> but the total amount of *code* in the framework goes down significantly
> and each package is easier to understand, I'm happy to see the amount of
> packages go up.

=lots. Smaller, easier to comprehent packages should be a major goal.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJuC6j+gerLs4ltQ4RArvxAKCTzJFoNUSUmgWVwsuBl9RgMgvEhQCgnaFW
tR2pkFQjxHl0Xrt8iaGmAaY=
=pVpO
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


tseaver at palladion

Mar 11, 2009, 2:35 PM

Post #19 of 27 (2678 views)
Permalink
Re: zope.password [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hi there,
>
> Stephan Richter wrote:
> [snip]
>>> In my opinion going for an extra here just to avoid this is speculating
>>> a bit too much right now. Do we really have users that want to use
>>> zope.password and really don't want zope.component and zope.schema? If
>>> so, we'll hear from them when they speak up and *then* declare an extra
>>> or take some other action.
>> +1. I want more of our decisions to go into this direction. It is a sign that
>> we turn the # of packages knob as well.
>
> I agree with you in the case against extras.
>
> It appears though that Dan has a concrete use case for using
> zope.password in a Pylons app where he isn't interested in
> zope.component, so I'm +1 on the extra in this case. We'll see whether
> this leads to difficulties. Luckily the zope.component and zope.schema
> libraries are typically around anyway so it doesn't make reasoning about
> the graph that much harder.
>
> I'm just glad we actually had a quick discussion about this stuff, with
> some form of conclusion.
>
> On creating new packages, I think we're in a phase where we cannot avoid
> creating new packages for a bit. Before long I hope that this generation
> of more packages can allow us to seriously weed in the packages in the
> framework. Zope 3 + ZMI will need a lot more packages for a while, but
> anything that doesn't need the ZMI (Grok, Zope 2) will hopefully use a
> lot less. In addition I hope more of our packages will be reusable
> independently as a result.

We should be trying to get all zope.app.* dependencies out of the Zope2
graph ASAP (before 2.12 final would be ideal).

> I hope that some group will start to take care of Zope 3 and perhaps
> consolidate a lot of ZMI code into one or more zmi.* packages eventually
> too.
>
> Besides the reusability argument and weeding argument for more packages,
> I'll also note that if the amount of packages in the framework goes up
> but the total amount of *code* in the framework goes down significantly
> and each package is easier to understand, I'm happy to see the amount of
> packages go up.

=lots. Smaller, easier to comprehent packages should be a major goal.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJuC6j+gerLs4ltQ4RArvxAKCTzJFoNUSUmgWVwsuBl9RgMgvEhQCgnaFW
tR2pkFQjxHl0Xrt8iaGmAaY=
=pVpO
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


ct at gocept

Mar 18, 2009, 1:19 AM

Post #20 of 27 (2528 views)
Permalink
Re: zope.password [In reply to]
On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote:
> Hi there,
>
> Stephan Richter wrote:
> [snip]
> >> In my opinion going for an extra here just to avoid this is speculating
> >> a bit too much right now. Do we really have users that want to use
> >> zope.password and really don't want zope.component and zope.schema? If
> >> so, we'll hear from them when they speak up and *then* declare an extra
> >> or take some other action.
> >
> > +1. I want more of our decisions to go into this direction. It is a sign that
> > we turn the # of packages knob as well.
>
> I agree with you in the case against extras.
>
> It appears though that Dan has a concrete use case for using
> zope.password in a Pylons app where he isn't interested in
> zope.component, so I'm +1 on the extra in this case. We'll see whether
> this leads to difficulties. Luckily the zope.component and zope.schema
> libraries are typically around anyway so it doesn't make reasoning about
> the graph that much harder.

I remember that at the sprint we used to identify packages which are
"always good". E.g. zope.interface is a declared no-brainer to add to
your dependencies. The other two that keep popping up that we *might*
wanna white-list are zope.schema and zope.component.

In addition this would need documentation as well.

Christian

--
Christian Theune · ct [at] gocept
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development
Attachments: signature.asc (0.19 KB)


tseaver at palladion

Mar 18, 2009, 4:16 AM

Post #21 of 27 (2536 views)
Permalink
Re: zope.password [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Theune wrote:
> On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote:
>> Hi there,
>>
>> Stephan Richter wrote:
>> [snip]
>>>> In my opinion going for an extra here just to avoid this is speculating
>>>> a bit too much right now. Do we really have users that want to use
>>>> zope.password and really don't want zope.component and zope.schema? If
>>>> so, we'll hear from them when they speak up and *then* declare an extra
>>>> or take some other action.
>>> +1. I want more of our decisions to go into this direction. It is a sign that
>>> we turn the # of packages knob as well.
>> I agree with you in the case against extras.
>>
>> It appears though that Dan has a concrete use case for using
>> zope.password in a Pylons app where he isn't interested in
>> zope.component, so I'm +1 on the extra in this case. We'll see whether
>> this leads to difficulties. Luckily the zope.component and zope.schema
>> libraries are typically around anyway so it doesn't make reasoning about
>> the graph that much harder.
>
> I remember that at the sprint we used to identify packages which are
> "always good". E.g. zope.interface is a declared no-brainer to add to
> your dependencies. The other two that keep popping up that we *might*
> wanna white-list are zope.schema and zope.component.

That woould imply the transitive closure of their dependencies, which
would be:

- - zope.event

- - zope.i18nmessageid

- - zope.interface

- - zope.component

- - zope.schema

We would need to finish trimming off the zope.component extras, first.
Once done, those pacakges are all essentially "libraries," and could be
managed as a "chunk."

> In addition this would need documentation as well.

Fleshing out the in-package narrative docs for those packages (or
perhaps for the set?) would be pretty valuable, too.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJwNge+gerLs4ltQ4RAtV8AKC0+44VxwGBq4n65uwM+ry4xRQfsQCfbQTQ
klc7Xe1goO+nSPfaAflpl48=
=2+XJ
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


shane at hathawaymix

Mar 18, 2009, 12:07 PM

Post #22 of 27 (2533 views)
Permalink
Re: zope.password [In reply to]
Christian Theune wrote:
> I remember that at the sprint we used to identify packages which are
> "always good". E.g. zope.interface is a declared no-brainer to add to
> your dependencies. The other two that keep popping up that we *might*
> wanna white-list are zope.schema and zope.component.

To whitelist zope.component would be quite interesting. As I recall,
there was a time when all packages that depended on zope.component were
required to be in the zope.app namespace.

I don't object to the idea, though. We're using zope.schema and
zope.component almost like language features.

Shane
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


ct at gocept

Mar 18, 2009, 11:42 PM

Post #23 of 27 (2523 views)
Permalink
Re: zope.password [In reply to]
On Wed, 2009-03-18 at 13:07 -0600, Shane Hathaway wrote:
> Christian Theune wrote:
> > I remember that at the sprint we used to identify packages which are
> > "always good". E.g. zope.interface is a declared no-brainer to add to
> > your dependencies. The other two that keep popping up that we *might*
> > wanna white-list are zope.schema and zope.component.
>
> To whitelist zope.component would be quite interesting. As I recall,
> there was a time when all packages that depended on zope.component were
> required to be in the zope.app namespace.

Interesting, didn't know/remember that.

> I don't object to the idea, though. We're using zope.schema and
> zope.component almost like language features.

Same here.

--
Christian Theune · ct [at] gocept
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development
Attachments: signature.asc (0.19 KB)


wichert at wiggy

Sep 23, 2009, 1:07 AM

Post #24 of 27 (1669 views)
Permalink
Re: zope.password [In reply to]
On 2009-9-22 18:59, Daniel Holth wrote:
> At least on Python 2.6, SSHAPasswordManager().checkPassword(hash,
> password) fails if hash is unicode, which it always is if stored in some
> databases. SSHAPasswordManager should encode the hash to utf-8 before
> trying to un-base64.

Isn't that a bug in those databases. The hash is not a unicode string
but a bytestring.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


dholth at gmail

Sep 23, 2009, 4:29 AM

Post #25 of 27 (1641 views)
Permalink
Re: zope.password [In reply to]
sqlite for example will always return strings as unicode strings, or
it will always return strings as byte strings. It doesn't know how to
return the username colum as one kind of string and the hash column as
another kind of string.

I think this is really a bug in the urlsafe base64 module. This works:
unicode(u"foobar".encode('base64')).decode('base64')

On Wed, Sep 23, 2009 at 4:07 AM, Wichert Akkerman <wichert [at] wiggy> wrote:
> On 2009-9-22 18:59, Daniel Holth wrote:
>>
>> At least on Python 2.6, SSHAPasswordManager().checkPassword(hash,
>> password) fails if hash is unicode, which it always is if stored in some
>> databases. SSHAPasswordManager should encode the hash to utf-8 before
>> trying to un-base64.
>
> Isn't that a bug in those databases. The hash is not a unicode string but a
> bytestring.
>
> Wichert.
>
> --
> Wichert Akkerman <wichert [at] wiggy>   It is simple to make things.
> http://www.wiggy.net/                  It is hard to make things simple.
>
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

First page Previous page 1 2 Next page Last page  View All Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.