created src and move typeagent to src

[bmerkle]

• create src
• move typeagent to src
• adapt config files

#125

[gvanrossum]

Just two tiny suggestions and one formatting nit. I will merge after you fix those.

[gvanrossum]

Oh, and you need to merge the conflict caused by me merging my unused-xxx fix first (Rob was okay reviewing it).

[gvanrossum]

You're on Windows, right? Did you look at what needs to change in Makefile? The format and check entries need to change typeagent to src, and the mcp entry needs to use src/typeagent.

[gvanrossum]

in get_keys.py i get a make format modification which was not commited in main branch. it breaks it in several lines, not sure if CodeQL will accept that.

   self.credential = (
          DefaultAzureCredential()
      )  # CodeQL [SM05139] - This code is used as part of development setup only.

Rob is working on that in #131. For now ignore those errors.

[bmerkle]

ok I have pushed. Should be fine now.

[gvanrossum]

I think your tests are failing because of #133. I will retest locally (I have a workaround) and then merge.

[gvanrossum]

Sorry, I can't merge this by myself. I need @robgruen's approval for my suggestions that were merged. (Re-approving doesn't help.)

[gvanrossum]

And it still won't merge. @robgruen can you merge this? Otherwise we're stuck.

[bmerkle]

when we have merged this PR into main, I would create a new PR for the remaining topics of #125

the PR is already here https://github.com/bmerkle/typeagent-py/tree/125

I hope it is ok the make the remaining steps in one PR ?

• move test 125-tests
• introduce samples 125-samples
• move spec-to-docs 125-spec

after that the structure should be ok, and we can continue with functional improvements

[gvanrossum]

Can we just move test to tests? I'm not convinced we need a samples subdir (is that even a standard? and it feels like an odd word to me). The spec subdir probably needs to be deleted, not moved -- it was part of a failed AI experiment (the AI generated the spec but then wasn't able to implement it, and I couldn't get myself to edit it, it was way too verbose and repetitive). You can delete spec/ in a separate PR since it can be merged independent from everything else.

[gvanrossum]

I wonder if we could make progress here if you did something like this:

• git checkout 125-src-create
• git diff main >125.diff
• git branch 125-redo
• git checkout 125-redo # <----------------- IMPORTANT
• git apply 125.diff
• (git commit?)
• git push
• make a few PR from the new branch

That would have a cleaner history (a single commit, by you) and maybe if I approve it I can merge it.

[gvanrossum]

Note I added a step after that comment sent an email -- use the version on GitHub, not the email (if you read those).

[bmerkle]

yup, we can make

• one PR with move of test to tests
• a second PR with rearrangement of samples, docs, specs, examples. I described a bit in migrate to python standard project layout #125 what would make sense, but it do not know if there are any outdate files which should be deleted.
• IIRC most github repos have an "examples" in parallel to "src" where you can look how the framework is used etc. (so not "samples" but "examples"

[gvanrossum]

Please make the one to move test -> tests (with tool updates including Makefile). For the other stuff there's not that much to gain from the rearrangement, I'd like to wait on that. But go ahead and delete spec/ as a separate PR (as it affects no tools).

[bmerkle]

I wonder if we could make progress here if you did something like this:

• git checkout 125-src-create
• git diff main >125.diff
• git branch 125-redo
• git checkout 125-redo # <----------------- IMPORTANT
• git apply 125.diff
• (git commit?)
• git push
• make a few PR from the new branch

That would have a cleaner history (a single commit, by you) and maybe if I approve it I can merge it.

i could squash it if that is want you mean ?

[gvanrossum]

i could squash it if that is want you mean ?

I've never used squash, but it sounds like it might work. Key requirement for a clean merge is (1) one diff, (2) authored by you only, and probably (3) in a new branch and PR.