New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use portend for port checking/waiting #1332

Closed
bb-migration opened this Issue Jul 13, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@bb-migration

bb-migration commented Jul 13, 2014

Originally reported by: Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco)


I've extracted and made more general purpose the port checking routines in cherrypy.process.servers in a new package called portend.

CherryPy should consider using that package.


@bb-migration

This comment has been minimized.

Show comment
Hide comment
@bb-migration

bb-migration Jul 13, 2014

Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco):


In my fork, I've added this commit as a point of discussion. I've not tested the patch, only drafted it, but please do comment on the approach.

I note that while this patch does add the first dependency on CherryPy, the concept of dependencies has been already approved. The focus here should be on the value of using the implementation in portend or keeping a separate implementation in CherryPy.

bb-migration commented Jul 13, 2014

Original comment by Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco):


In my fork, I've added this commit as a point of discussion. I've not tested the patch, only drafted it, but please do comment on the approach.

I note that while this patch does add the first dependency on CherryPy, the concept of dependencies has been already approved. The focus here should be on the value of using the implementation in portend or keeping a separate implementation in CherryPy.

@bb-migration

This comment has been minimized.

Show comment
Hide comment
@bb-migration

bb-migration Jul 15, 2014

Original comment by Sylvain Hellegouarch (Bitbucket: Lawouach, GitHub: Lawouach):


Hi Jason,

So far, our dependencies have been to enable some specific features. None have forced a requirement on CherryPy. Just for that reason, I'm not sure I'm happy with breaking that historical convention.

bb-migration commented Jul 15, 2014

Original comment by Sylvain Hellegouarch (Bitbucket: Lawouach, GitHub: Lawouach):


Hi Jason,

So far, our dependencies have been to enable some specific features. None have forced a requirement on CherryPy. Just for that reason, I'm not sure I'm happy with breaking that historical convention.

@webknjaz

This comment has been minimized.

Show comment
Hide comment
@webknjaz

webknjaz Sep 25, 2016

Member

@jaraco to use it, first switch tests to run against all supported versions.
And there's a dependency for tempora.timing. Don't you think it's an overhead to depend on another package just to use a stopwatch?

Member

webknjaz commented Sep 25, 2016

@jaraco to use it, first switch tests to run against all supported versions.
And there's a dependency for tempora.timing. Don't you think it's an overhead to depend on another package just to use a stopwatch?

@jaraco

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Sep 28, 2016

Member

It is extra overhead, and yes, it's worth the overhead. After several years of accepting that 'copy/paste' is acceptable, I'm of the opinion that if someone is willing to maintain a library with suitable functionality that it's better to use that library than to create a fork of that functionality (by inlining it). The maintenance costs of subtly divergent implementations of essentially the same functionality are far greater than the costs of incorporating dependencies.

Member

jaraco commented Sep 28, 2016

It is extra overhead, and yes, it's worth the overhead. After several years of accepting that 'copy/paste' is acceptable, I'm of the opinion that if someone is willing to maintain a library with suitable functionality that it's better to use that library than to create a fork of that functionality (by inlining it). The maintenance costs of subtly divergent implementations of essentially the same functionality are far greater than the costs of incorporating dependencies.

@webknjaz

This comment has been minimized.

Show comment
Hide comment
@webknjaz

webknjaz Sep 28, 2016

Member

Okay, I agree with that

Member

webknjaz commented Sep 28, 2016

Okay, I agree with that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment