Menu
▾
▴
jython-dev
|
From: Jeff A. <ja...@fa...> - 2020-05-25 15:43:26
|
We've wanted to do this for ages. If you go back far enough, you can find Jim confidently asserting we'd use GitHub for 2.7.2 (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). Building with Gradle and accessing dependencies remotely (no JARs checked in) were identified as prerequisites at the time. In turn, I think building with Gradle requires re-organising the code to fit with its /convention over configuration/ idea (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). At least, doing otherwise in 2.7.2 got too difficult for me, somewhere around exposed classes ISTR. These don't seem to be prerequisites for the move. I would do Jython 3 that way, but leave 2.7.3 as it is. https://bugs.jython.org/issue2892 opened to cover this. I'll try, starting withthe obvious way (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) and reading what CPython did. I'd be happy to take input from anyone with a sure-fire answer. -- Jeff Allen |
|
From: Jim B. <jim...@py...> - 2020-05-26 00:33:00
|
On Mon, May 25, 2020 at 9:43 AM Jeff Allen <ja...@fa...> wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > ( > https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683 > ). > Hah, yes, I had much more confidence back before we got stuck on some critical bugs finally resolved with the actual 2.7.2. > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > +100 > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > For sure, we need to do this, under https://github.com/jython/jython Ideally we would replace the Jython 3 sandbox t https://github.com/jython/jython3 with just a README that that points to this historical work, but otherwise is empty. (If this were a sandbox under someone's name I would keep as is, but under this name we have to do this cleanup to avoid confusion.) One other thing we should consider in this move to GitHub is the overall workflow. I suggest we switch over to GitHub issues, and anything else accommodated by the GitHub ecosystem (eg https://github.com/features/actions). So I wouldn't want to spend time investing in implementing the full CPython workflow here like Discourse - standard GitHub is more than adequate for our needs. Given that Jython 3 will have effectively its own bugs, this can be a good clean break with bugs.jython.org as it is - I would keep around historically, but I wouldn't bother porting over these possibly irrelevant issues into GitHub. However, we would need to do something to ensure that bugs are not inadvertently reported there - an advisory notice somewhere on that site should suffice. > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > ( > https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > > -- > Jeff Allen > |
|
From: Jeff A. <ja...@fa...> - 2020-06-02 12:23:29
|
On 26/05/2020 06:13, Jim Baker wrote: > On Mon, May 25, 2020 at 9:43 AM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > For sure, we need to do this, under https://github.com/jython/jython > Ideally we would replace the Jython 3 sandbox > thttps://github.com/jython/jython3 with just a README that that points > to this historical work, but otherwise is empty. (If this were a > sandbox under someone's name I would keep as is, but under this name > we have to do this cleanup to avoid confusion.) I'm making reasonable progress in that direction and you can read the fun on https://bugs.jython.org/issue2892 . GitHub lets us make repositories private now. Is that a good answer? > One other thing we should consider in this move to GitHub is the > overall workflow. I suggest we switch over to GitHub issues, and > anything else accommodated by the GitHub ecosystem (eg > https://github.com/features/actions). So I wouldn't want to spend time > investing in implementing the full CPython workflow here like > Discourse - standard GitHub is more than adequate for our needs. Given > that Jython 3 will have effectively its own bugs, this can be a good > clean break with bugs.jython.org <http://bugs.jython.org> as it is - I > would keep around historically, but I wouldn't bother porting over > these possibly irrelevant issues into GitHub. However, we would need > to do something to ensure that bugs are not inadvertently reported > there - an advisory notice somewhere on that site should suffice. Definitely, when there is a Jython 3 to have bugs, we only want them in one place. CPython are keeping bugs.python.org around, but they've been maintaining it. It is still the basis of the PSF CLA process that covers us. (I'm quite keen to keep that.) Our bugs.jython.org is looking increasingly fragile, so I agree we should discourage reports there, but I think we'd accept them, and there are quite a few outstanding issues we probably need until Jython 2.7 is no longer maintained. Jeff |
|
From: Eero A. <eer...@ik...> - 2020-05-28 12:13:36
|
On Mon, May 25, 2020 at 6:43 PM Jeff Allen <ja...@fa...> wrote: > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > Regarding the jars, are you * going to keep the history intact and the jars in the resulting Git repository or * a harsher break dropping the binaries completely? -- Eero Aaltonen |
|
From: Jeff A. <ja...@fa...> - 2020-05-28 19:14:25
|
On 28/05/2020 13:13, Eero Aaltonen wrote: > On Mon, May 25, 2020 at 6:43 PM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit > with > its /convention over configuration/ idea > (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, > somewhere > around exposed classes ISTR. > > > Regarding the jars, are you > * going to keep the history intact and the jars in the resulting Git > repository or > * a harsher break dropping the binaries completely? What we have (jars and all) will be on the 2.7 branch, where Gradle would not go any further than I got with jython-slim. GitHub discourages large binary files, and large repos generally, but we're not at the point where it makes us use their large file store. I've been doing a project with just Gradle (and structured according to Gradle's liking, which was my point). I foresee a 3.8 branch built the same way and not using ant or checking in dependencies at all. Jeff Allen |
|
From: Eero A. <eer...@ik...> - 2020-05-29 08:16:35
|
On Thu, May 28, 2020 at 10:14 PM Jeff Allen <ja...@fa...> wrote: > On 28/05/2020 13:13, Eero Aaltonen wrote: > > Regarding the jars, are you > * going to keep the history intact and the jars in the resulting Git > repository or > * a harsher break dropping the binaries completely? > > What we have (jars and all) will be on the 2.7 branch, where Gradle would > not go any further than I got with jython-slim. GitHub discourages large > binary files, and large repos generally, but we're not at the point where > it makes us use their large file store. > This will incur a cost when doing an initial clone of the repository, as Git will compress everything before transferring over the network. If you don't have heavy CI and generally keep existing clones, the cost should amortize reasonably. -- Eero Aaltonen > |
|
From: <fwi...@gm...> - 2020-05-28 23:56:03
|
On Mon, May 25, 2020 at 8:44 AM Jeff Allen <ja...@fa...> wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > ( > https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683 > ). > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > ( > https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > Great news! -Frank |
|
From: Jeff A. <ja...@fa...> - 2020-06-03 10:49:39
|
Ok, I seem to be ready so will try for real. Details on https://bugs.jython.org/issue2892 . I'll try today, but I think there is a fair amount of manual work to migrate issues/PRs. Some references will probably break. Jeff Allen |
|
From: Jeff A. <ja...@fa...> - 2020-06-05 07:55:27
|
Welcome to your new home: https://github.com/jython/jython Take a look around. I'm sincerely hoping this works for us all, or is only wrong in ways we can put right. If you find this is irreparably messed up, we may be able to start over. Otherwise, I think this is where we now invite contribution and fix issues. After a day or two cooling off, I propse we ask the Ernest and the infrastructure team to make hg.python.org/jython read-only in some gentle way we could reverse if we had to. Anything other loose ends? Jeff Jeff Allen On 25/05/2020 16:42, Jeff Allen wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > |
|
From: Adam B. <ada...@gm...> - 2020-06-11 06:34:57
|
Basic test drives and sanity tests worked for me:
+ cloned new repo on a new (windows) machine
+ built from ant
+ ran gradle but got a deprecation warning which seems to be the current
state
+ spun up the console, did a few simple things
+ ran system tests and got current expected state
7 tests skipped:
test_codecmaps_hk test_curses test_smtpnet test_socketserver
test_subprocess test_urllib2net test_urllibnet
0 tests failed:
Platform:
'Java-13.0.2-OpenJDK_64-Bit_Server_VM,_13.0.2+8,_Oracle_Corporation-on-Windows_10-10.0-amd64'
Command line:
['C:\\Users\\burkeat\\jython\\jython1\\jython\\dist\\Lib\\test\\regrtest.py',
'-e', '-m', 'regrtest_memo.txt']
Cheers
Adam
On Fri, 5 Jun 2020 at 17:55, Jeff Allen <ja...@fa...> wrote:
> Welcome to your new home: https://github.com/jython/jython
>
> Take a look around. I'm sincerely hoping this works for us all, or is only
> wrong in ways we can put right. If you find this is irreparably messed up,
> we may be able to start over. Otherwise, I think this is where we now
> invite contribution and fix issues.
>
> After a day or two cooling off, I propse we ask the Ernest and the
> infrastructure team to make hg.python.org/jython read-only in some gentle
> way we could reverse if we had to.
>
> Anything other loose ends?
>
> Jeff
>
> Jeff Allen
>
> On 25/05/2020 16:42, Jeff Allen wrote:
>
> We've wanted to do this for ages. If you go back far enough, you can find
> Jim confidently asserting we'd use GitHub for 2.7.2 (
> https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683
> ).
>
> Building with Gradle and accessing dependencies remotely (no JARs checked
> in) were identified as prerequisites at the time. In turn, I think building
> with Gradle requires re-organising the code to fit with its /convention
> over configuration/ idea (
> https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions).
> At least, doing otherwise in 2.7.2 got too difficult for me, somewhere
> around exposed classes ISTR.
>
> These don't seem to be prerequisites for the move. I would do Jython 3
> that way, but leave 2.7.3 as it is.
>
> https://bugs.jython.org/issue2892 opened to cover this. I'll try,
> starting withthe obvious way (
> https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer)
> and reading what CPython did. I'd be happy to take input from anyone with a
> sure-fire answer.
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Jeff A. <ja...@fa...> - 2020-06-12 06:03:02
|
Thanks for testing in your environment. That's a good reassurance I haven't made a dud. Presumably it now also signs on with a sensible sensible change set reference, instead of just grumbling about being an uncontrolled copy. (ISTR you used to see that when working git-based. We've caught up with you.) I think we should say jython/jython is open for business. Anyone have misgivings? Jeff Jeff Allen On 11/06/2020 07:34, Adam Burke wrote: > Basic test drives and sanity tests worked for me: > > + cloned new repo on a new (windows) machine > + built from ant > + ran gradle but got a deprecation warning which seems to be the > current state > + spun up the console, did a few simple things > + ran system tests and got current expected state > > 7 tests skipped: > test_codecmaps_hk test_curses test_smtpnet test_socketserver > test_subprocess test_urllib2net test_urllibnet > 0 tests failed: > > Platform: > 'Java-13.0.2-OpenJDK_64-Bit_Server_VM,_13.0.2+8,_Oracle_Corporation-on-Windows_10-10.0-amd64' > Command line: > ['C:\\Users\\burkeat\\jython\\jython1\\jython\\dist\\Lib\\test\\regrtest.py', > '-e', '-m', 'regrtest_memo.txt'] > > Cheers > Adam > > On Fri, 5 Jun 2020 at 17:55, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > Welcome to your new home: https://github.com/jython/jython > > Take a look around. I'm sincerely hoping this works for us all, or > is only wrong in ways we can put right. If you find this is > irreparably messed up, we may be able to start over. Otherwise, I > think this is where we now invite contribution and fix issues. > > After a day or two cooling off, I propse we ask the Ernest and the > infrastructure team to make hg.python.org/jython > <http://hg.python.org/jython> read-only in some gentle way we > could reverse if we had to. > > Anything other loose ends? > > Jeff > > Jeff Allen > > On 25/05/2020 16:42, Jeff Allen wrote: >> We've wanted to do this for ages. If you go back far enough, you >> can find Jim confidently asserting we'd use GitHub for 2.7.2 >> (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). >> >> Building with Gradle and accessing dependencies remotely (no JARs >> checked in) were identified as prerequisites at the time. In >> turn, I think building with Gradle requires re-organising the >> code to fit with its /convention over configuration/ idea >> (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). >> At least, doing otherwise in 2.7.2 got too difficult for me, >> somewhere around exposed classes ISTR. >> >> These don't seem to be prerequisites for the move. I would do >> Jython 3 that way, but leave 2.7.3 as it is. >> >> https://bugs.jython.org/issue2892 opened to cover this. I'll try, >> starting withthe obvious way >> (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) >> and reading what CPython did. I'd be happy to take input from >> anyone with a sure-fire answer. >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X