Re: Closing out 2.7 beta 4

Jim Baker <[email protected]>
Newsgroups gmane.comp.lang.jython.devel
Message-ID <CAOhO=aM_R3mcBasM21-TBaMG3LoZ5tT+iQzHBGbsYZJWDLT5Ag@mail.gmail.com>
On Mon, Oct 13, 2014 at 1:37 AM, Pekka Klärck <[email protected]> wrote:

> 2014-10-13 6:41 GMT+03:00 Jim Baker <[email protected]>:
> >
> > Jython 2.7.0 has been under active development since the PyCon sprints in
> > March 2011. It’s about time we brought this to a close! Therefore I would
> > like to propose that the beta 4 work be completed by the end of this
> month
> > (Friday October 31), or at the very least by one week later (November 7).
>
> +1
>
> > Under this schedule, because beta 4 is our last beta, in 3 to 4 weeks we
> > will be absolutely done with new features and will only focus on
> > stabilization and high priority bug fixes for a release candidate well
> > before the end of the year.
>
> Does new features above also include fixes to the standard library to
> match what is available in Python 2.7? One thing I'd like to look at
> is adding support for Popen.terminate() (and possibly also
> Popen.send_signal()), but I'm not sure when I actually have time for
> that. Such an isolated fix ought to be safe to add also later in rc
> phase, but I also understand if you want to set rules otherwise.
>

Beta 3 has this support: Popen now implements kill, send_signal, and
terminate methods.

In other cases, implementing small isolated bits like this would certainly
be reasonable in the rc. Contrast this with something like a new feature to
support better Java integration, eg, arbitrary callable objects can be used
as a target of a single method interface in a callback (
http://bugs.jython.org/issue2115).


> > In addition, I would like to suggest that we provide a beta 4 preview by
> > using the soft beta process, just so people can try out what is now
> > available, such as better Django support, without having to build their
> own
> > release with ant. Let’s have this done by the end of the week.
>
> Personally I found soft releases somewhat confusing and delayed
> actually testing beta 3 because of them. I also didn't want to
> recommend our users to test them because it wasn't clear what the
> status actually was. What are the benefits of this approach compared
> to just releasing more betas if there are problems with earlier
> versions? If the main motivation is to make it easier to test the
> latest code, wouldn't it be better to make the process to checkout out
> and compiling the code easier?
>

We will want to revisit this process going forward with 2.7.1. Other
projects do more frequent iterations, such as Netty, and feature nightly
builds as well. As part of that, expect to see us implementing Maven-based
builds sometime in the future http://bugs.jython.org/issue2182


>
> > Deferred to 2.7.1 (or later)
> >
> > ensurepip and venv.
>
> Does that mean there is no built-in pip support in 2.7? Will pip work
> if installed separately?
>

Right now use https://github.com/jythontools/pip - I use that all the time
and it works fine.

I would expect to see the default pip to have support for Jython sometime
soon, and certainly a part of the RC process is ensuring this is the case
by working with upstream.

However, supporting ensurepip means that pip is available out-of-the-box
with Jython, and if necessary we can control where it's coming from in case
upstream pip is not working.

- Jim

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.