jython-dev

The instructions for building Jython talk about getting the library
from the Python 2.2.3 release.
Proposal: switch to using the Lib/ directory from the
release2{2,3,...}-maint branch in CPython's SVN. This would let us
expand tests and benefit from bugfixes that didn't get into any
released version of Python. We can use an svn:externals property in
the SVN tree to automatically check out a copy of the library from any
particular branch we desire.
Motivation: I've just discovered that the sha module in Jython 2.3
(and presumably 2.2 as well) has various problems, but the test_sha
script doesn't exercise very much and doesn't manifest the problem.
I'd like to expand the test suite with a test that would have caught
the bug (hey, maybe PyPy or IronPython have a similar bug), but
committing it to CPython's trunk or the release23-maint branch doesn't
help Jython at all. If Jython used the library from CPython's SVN, we
can commit tests and fixes as we go, and CPython benefits, too
(especially once Jython is using the 25-maint branch someday).
BTW, I'm working on a patch for the SHA problems and will file a bug
in a little while.
--amk

This seems like a good idea to me. Unless anyone objects, I'll add
'CPythonLib' as an external in trunk and the 2.3 branch.
Unfortunately, we can't use 'Lib' since we've already got our slightly
modified versions of several CPython Lib files in there. Hopefully we
can use this as a starting point for moving the modifications back to
CPython and unifying things.
Charlie
On 11/18/06, A.M. Kuchling <amk@...> wrote:
> The instructions for building Jython talk about getting the library
> from the Python 2.2.3 release.
>
> Proposal: switch to using the Lib/ directory from the
> release2{2,3,...}-maint branch in CPython's SVN. This would let us
> expand tests and benefit from bugfixes that didn't get into any
> released version of Python. We can use an svn:externals property in
> the SVN tree to automatically check out a copy of the library from any
> particular branch we desire.
>
> Motivation: I've just discovered that the sha module in Jython 2.3
> (and presumably 2.2 as well) has various problems, but the test_sha
> script doesn't exercise very much and doesn't manifest the problem.
> I'd like to expand the test suite with a test that would have caught
> the bug (hey, maybe PyPy or IronPython have a similar bug), but
> committing it to CPython's trunk or the release23-maint branch doesn't
> help Jython at all. If Jython used the library from CPython's SVN, we
> can commit tests and fixes as we go, and CPython benefits, too
> (especially once Jython is using the 25-maint branch someday).
>
> BTW, I'm working on a patch for the SHA problems and will file a bug
> in a little while.
>
> --amk
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Charlie Groves wrote:
> This seems like a good idea to me. Unless anyone objects, I'll add
> 'CPythonLib' as an external in trunk and the 2.3 branch.
> Unfortunately, we can't use 'Lib' since we've already got our slightly
> modified versions of several CPython Lib files in there. Hopefully we
> can use this as a starting point for moving the modifications back to
> CPython and unifying things.
Oh, please please do. When we made a similar change for JRuby by
including the full set of Ruby libraries in JRuby...well things just got
WORLDS easier to distribute, deploy, and develop.
Anything that makes it possible to check out, run ant, and be done is a
good move in my book. All that other configuration nonsense is a total
non-starter.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ http://www.headius.com/rubyspec
headius@... -- charles.nutter@...

On 11/19/06, Charlie Groves <charlie.groves@...> wrote:
> This seems like a good idea to me. Unless anyone objects, I'll add
> 'CPythonLib' as an external in trunk and the 2.3 branch.
Please do! I've been meaning to do this for a while...
-Frank

Done.
I updated build.xml to point at the checked out Lib directory, so
after an svn up you should get the new Lib files. If not, you may
need to delete python.lib from ant.properties in the base of your
checkout.
Charlie
On 11/19/06, Frank Wierzbicki <fwierzbicki@...> wrote:
> On 11/19/06, Charlie Groves <charlie.groves@...> wrote:
> > This seems like a good idea to me. Unless anyone objects, I'll add
> > 'CPythonLib' as an external in trunk and the 2.3 branch.
> Please do! I've been meaning to do this for a while...
>
> -Frank
>

Charlie,
thanks!
You changed the build for the developer build.
If I understand it correctly, the full build should be changed, too.
Up to now, we checked out the full CPython source (still from cvs,
which was wrong, I suppose:-)* and copied the /Lib files over.
If you don't mind, I will now change the full build to use the
external CPythonLib instead.
This will make it a lot easier. Please give me some hours. I'll test
it as deeply as I can, and would speak up if I have problems.
Regarding a beta: What never has been tested is a full build against a
svn tag (since we don't have one yet). So there might be a surprise. I
think it is the best to plan a little time to get it really running,
as soon as we are there.
best wishes,
Oti.
* happy I did not write down these snapshot build instructions yet ...
On 11/21/06, Charlie Groves <charlie.groves@...> wrote:
> Done.
>
> I updated build.xml to point at the checked out Lib directory, so
> after an svn up you should get the new Lib files. If not, you may
> need to delete python.lib from ant.properties in the base of your
> checkout.
>
> Charlie
>
> On 11/19/06, Frank Wierzbicki <fwierzbicki@...> wrote:
> > On 11/19/06, Charlie Groves <charlie.groves@...> wrote:
> > > This seems like a good idea to me. Unless anyone objects, I'll add
> > > 'CPythonLib' as an external in trunk and the 2.3 branch.
> > Please do! I've been meaning to do this for a while...
> >
> > -Frank
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Charlie,
by revision 2984, the full-build has become a lot simpler, taking
advantage of the new CPythonLib directory.
I ran it without any problems, and successfully stress tested the
resulting jython_HEAD.jar with:
java -jar jython_HEAD.jar -A
This means the build / install cycle is fine.
I also manually checked that the Lib files are there.
2 Questions:
full-build only copies defined .py files over from CPythonLib.
The include set is defined in build.Lib.include.properties.
Is this still up to date, or do we need to include more files ?
The CPython license text is still copied from ${python.home}, which is
a local CPython installation on the build machine, and therefore
potentially the wrong file. We could use the svn:externals trick here
as well. But AFAICS svn:externals only supports directories, not
single files. So this maybe would be too much of overhead. Therefore I
tend to leave it as it is. What do you think ?
Best wishes,
Oti.
On 11/21/06, Oti <ohumbel@...> wrote:
> Charlie,
>
> thanks!
>
> You changed the build for the developer build.
> If I understand it correctly, the full build should be changed, too.
> Up to now, we checked out the full CPython source (still from cvs,
> which was wrong, I suppose:-)* and copied the /Lib files over.
>
> If you don't mind, I will now change the full build to use the
> external CPythonLib instead.
> This will make it a lot easier. Please give me some hours. I'll test
> it as deeply as I can, and would speak up if I have problems.
>
> Regarding a beta: What never has been tested is a full build against a
> svn tag (since we don't have one yet). So there might be a surprise. I
> think it is the best to plan a little time to get it really running,
> as soon as we are there.
>
> best wishes,
> Oti.
>
> * happy I did not write down these snapshot build instructions yet ...
>
>
> On 11/21/06, Charlie Groves <charlie.groves@...> wrote:
> > Done.
> >
> > I updated build.xml to point at the checked out Lib directory, so
> > after an svn up you should get the new Lib files. If not, you may
> > need to delete python.lib from ant.properties in the base of your
> > checkout.
> >
> > Charlie
> >
> > On 11/19/06, Frank Wierzbicki <fwierzbicki@...> wrote:
> > > On 11/19/06, Charlie Groves <charlie.groves@...> wrote:
> > > > This seems like a good idea to me. Unless anyone objects, I'll add
> > > > 'CPythonLib' as an external in trunk and the 2.3 branch.
> > > Please do! I've been meaning to do this for a while...
> > >
> > > -Frank
> > >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Jython-dev mailing list
> > Jython-dev@...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>

Oti wrote:
> The CPython license text is still copied from ${python.home}, which is
> a local CPython installation on the build machine, and therefore
> potentially the wrong file. We could use the svn:externals trick here
> as well. But AFAICS svn:externals only supports directories, not
> single files. So this maybe would be too much of overhead. Therefore I
> tend to leave it as it is. What do you think ?
Why not fetch that single file from a known HTTP URL?
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ http://www.headius.com/rubyspec
headius@... -- charles.nutter@...