Skip to content
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

Add visual studio project #138

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kiates
Copy link
Contributor

@kiates kiates commented Apr 5, 2023

It took me a bit of fiddling, since I don't know what I'm doing when it comes to python, but I was able to get a visual studio project going that supports running the UTs, and starting via the debugger. I was using VS 2022 Preview (why not go right to the latest), but probably works with other versions as well.

I did have to make some changes since I don't know of any way to work-around the console scripts that are installed for the country plugins to bootstrap things.

I'm not sure if there is another way, but at least with this I seem to be able to have access to tools I'm more used to. This will help me to better understand flow and maybe be in a better position to contribute going forward. Maybe this will be useful to others?

Unit Testing:
image

Debugging:
image

@kiates kiates force-pushed the add-visual-studio-project branch from 7d3c1d2 to 759d891 Compare April 5, 2023 04:28
@macanudo527
Copy link
Collaborator

Could you take the Pionex Documentation commit off of this?

@kiates kiates force-pushed the add-visual-studio-project branch from 759d891 to ea27e8c Compare April 6, 2023 01:44
Copy link
Owner

@eprbell eprbell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of providing IDE-specific configuration files, but this may require a bit more work (see comments).

Also, I'd like to move all VS-specific files to config/ide/visual_studio/, so that they don't crowd the top directory, but they are easy to access.

dali-rp2.pyproj Outdated
Comment on lines 31 to 35
<Content Include="src\dali_rp2.egg-info\dependency_links.txt" />
<Content Include="src\dali_rp2.egg-info\entry_points.txt" />
<Content Include="src\dali_rp2.egg-info\requires.txt" />
<Content Include="src\dali_rp2.egg-info\SOURCES.txt" />
<Content Include="src\dali_rp2.egg-info\top_level.txt" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These files are generated: I'm not sure they should be included in an IDE config file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I created the project I used Microsoft's "import" existing python project. That's probably why it included these. I've taken them out.

dali-rp2.pyproj Outdated
<ProjectTypeGuids>{888888a0-9f3d-457c-b088-3a5042f75d52}</ProjectTypeGuids>
<LaunchProvider>Standard Python launcher</LaunchProvider>
<InterpreterId>MSBuild|.venv|$(MSBuildProjectFullPath)</InterpreterId>
<CommandLineArguments>-t 1 -s -o C:\Users\cyates\Documents\rp2-files\cyates\dali-output -p cyates- C:\Users\cyates\Documents\rp2-files\cyates\cyates.ini</CommandLineArguments>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line has paths that point to a specific directory on your machine: it should be generic instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pointed this to the sample project.

dali-rp2.pyproj Outdated
<Folder Include="src\dali\plugin\input\rest" />
<Folder Include="src\dali\plugin\pair_converter" />
<Folder Include="src\dali\plugin\pair_converter\csv" />
<Folder Include="src\dali_rp2.egg-info" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also generated.

@@ -21,3 +21,8 @@
# JP-specific entry point
def dali_entry() -> None:
dali_main(JP())

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDE integration shouldn't require modifying the source code. I usually debug with print, but I did use the VSCode debugger occasionally in the past (not sure how similar it is to Visual Studio). VSCode can be configured to debug DaLI and RP2 without changing the source: I used .venv/bin/dali_us as the entry point.

Copy link
Contributor Author

@kiates kiates Apr 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can create IDE specific dali_us/dali_jp.py files for debugging, but I don't think that will be as simple as just adding this entry point. I couldn't figure out any way to get visual studio to start using the exe's generated by the "installer".

See this branch for what it would look like: https://github.com/kiates/dali-rp2/tree/visual-studio-project-improvements

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tried using .venv/bin/dali_us and .venv/bin/dali_jp as entry points? They should not require modification.

@@ -21,3 +21,8 @@
# US-specific entry point
def dali_entry() -> None:
dali_main(US())

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{21de6965-e7a9-45bf-bc35-9aafe37f7ddf}</ProjectGuid>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this id? Can it be shared on other user's machines?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a unique identify that represents this pyproject if it is inserted into a solution file. It isn't user specific.

<SearchPath />
<WorkingDirectory>.</WorkingDirectory>
<OutputPath>.</OutputPath>
<ProjectTypeGuids>{888888a0-9f3d-457c-b088-3a5042f75d52}</ProjectTypeGuids>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this id? Can it be shared on other user's machines?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a unique ID defined by Microsoft that indicates that this project is a python project type. It is the same for all python projects.

@kiates kiates force-pushed the add-visual-studio-project branch from ea27e8c to 45ffeea Compare April 7, 2023 04:29
@kiates kiates force-pushed the add-visual-studio-project branch from 45ffeea to 59e67ee Compare April 7, 2023 04:36
@kiates
Copy link
Contributor Author

kiates commented Apr 7, 2023

I tried some solutions to what your requesting, and I think it is more trouble than it is worth to fight how Visual Studio expects a python project to look like. In order to move the project/solution (pythonproject/sln) files to a sibling directory it requires changing all reference to source to a "linked" file rather than a normal file. This very robust, requires hand editing the files, and is a bit of a nightmare to maintain while breaking some of the IDE functionality to include/exclude source files. In addition the tests would no longer run for me (there may be a solution for that, but given the other problems I don't recommend trying to fight VS).

Also, if it was easy to have it in a sibling directory I would also recommend putting it in a ide or visual-studio/visual_studio directory rather than config as in config it is kind of hidden away in a directory that isn't related.

If you want to see my "experimentation" trying to get this going how you envision, see this branch in my fork: https://github.com/kiates/dali-rp2/tree/visual-studio-project-improvements.

If you aren't willing to take this in, I can just reserve on my fork for when I'm working with the project. It would just be nice to not have to maintain a fork, and could be useful to other VS contributors.

@eprbell
Copy link
Owner

eprbell commented Apr 7, 2023

I tried some solutions to what your requesting, and I think it is more trouble than it is worth to fight how Visual Studio expects a python project to look like. In order to move the project/solution (pythonproject/sln) files to a sibling directory it requires changing all reference to source to a "linked" file rather than a normal file. This very robust, requires hand editing the files, and is a bit of a nightmare to maintain while breaking some of the IDE functionality to include/exclude source files. In addition the tests would no longer run for me (there may be a solution for that, but given the other problems I don't recommend trying to fight VS).

Also, if it was easy to have it in a sibling directory I would also recommend putting it in a ide or visual-studio/visual_studio directory rather than config as in config it is kind of hidden away in a directory that isn't related.

If you want to see my "experimentation" trying to get this going how you envision, see this branch in my fork: https://github.com/kiates/dali-rp2/tree/visual-studio-project-improvements.

If you aren't willing to take this in, I can just reserve on my fork for when I'm working with the project. It would just be nice to not have to maintain a fork, and could be useful to other VS contributors.

I think it's worth experimenting in the direction you're going, but I would like to avoid IDE files in the root dir and IDE-specific changes to the source. The reason is that if we do that for every IDE the source tree will quickly become messy.

So I see the following options:

  • keep experimenting with it and we can revisit later, if you have a new version that meets the above requirements;
  • document it instead: we can have a file in docs describing what to do for various IDEs;
  • fork it (which is what you have done already).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants