In reply to @cldrpr:matrix.org
John Ericson: Re: GCC project - Requesting a review of my initial draft proposal (here: https://github.com/cloudripper/GSoC-24/blob/main/gsoc-proposal-draft.pdf). Please let me know if I need to be more granular or descriptive in my project plan or abstract - and if there are any other important project-specific sections you feel I should include (I will include other personal sections prior to submission). Additionally, if there are others interested in this project, I would be happy to modify as needed to try and avoid overlap.

In reply to @Ericson2314:matrix.org
I have a very specific vision in mind as to how this should work, and the draft PR already that was linked in the issue, but I expect to only be able to be able to convey that to anay mentee though an interative / dialogue process

Couple thoughts:

instead of changing instances of Path to
<code>std::filesystem::path</code>, what about changing <code>std::string
typedef</code> to <code>std::filesystem::path</code> - then working from
there. Keeps interface the same
for other developers and follows pre-established naming conventions. Looks
better being grouped with <code>CanonPath, Path, etc.</code> and makes more intuitive
sense not knowing the reason for <code>std::filesystem::path</code> and
using the other paths.

Could make some documentation that explains the mechanisms of Path and
what exactly it's invoking.
Other developers won't really need to know if it's cross-platform or not and
can happily carry on.

OR, what about making a class <code>Path</code> that handles the boiler-plate of conversion from <code>std::string</code> to <code>std::filesystem::path</code>, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something like <code>Path path</code> to <code>std::filesystem::path path</code> to be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existing <code>Path</code>

Both routes I think are effective and that's the real question.

Couple thoughts:

instead of changing instances of Path to
std::filesystem::path, what about changing std::string typedef to std::filesystem::path - then working from
there. Keeps interface the same
for other developers and follows pre-established naming conventions. Looks
better being grouped with CanonPath, Path, etc. and makes more intuitive
sense not knowing the reason for std::filesystem::path and
using the other paths.

Could make some documentation that explains the mechanisms of Path and
what exactly it's invoking.
Other developers won't really need to know if it's cross-platform or not and
can happily carry on.

OR, what about making a class Path that handles the boiler-plate of conversion from std::string to `std::filesystem::path</code>, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something like <code>Path path</code> to `std::filesystem::path pathto be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existingPath`

Both routes I think are effective and that's the real question.

Couple thoughts:

instead of changing instances of Path to
std::filesystem::path, what about changing std::string typedef to std::filesystem::path - then working from
there. Keeps interface the same
for other developers and follows pre-established naming conventions. Looks
better being grouped with CanonPath, Path, etc. and makes more intuitive
sense not knowing the reason for std::filesystem::path and
using the other paths.

Could make some documentation that explains the mechanisms of Path and
what exactly it's invoking.
Other developers won't really need to know if it's cross-platform or not and
can happily carry on.

OR, what about making a class Path that handles the boiler-plate of conversion from std::string to std::filesystem::path, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something likePath path to std::filesystem::path pathto be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existingPath

Both routes I think are effective and that's the real question.

Couple thoughts:

instead of changing instances of Path to
std::filesystem::path, what about changing std::string typedef to std::filesystem::path - then working from
there. Keeps interface the same
for other developers and follows pre-established naming conventions. Looks
better being grouped with CanonPath, Path, etc. and makes more intuitive
sense not knowing the reason for std::filesystem::path and
using the other paths.

Could make some documentation that explains the mechanisms of Path and
what exactly it's invoking.
Other developers won't really need to know if it's cross-platform or not and
can happily carry on.

OR, what about making a class Path that handles the boiler-plate of conversion from std::string to std::filesystem::path, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something likePath path to std::filesystem::path pathto be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existing Path

Both routes I think are effective and that's the real question.

Couple thoughts:

instead of changing instances of Path to std::filesystem::path, what about changing std::string typedef to std::filesystem::path - then working from
there. Keeps interface the same for other developers and follows pre-established naming conventions. Looks better being grouped with CanonPath, Path, etc. and makes more intuitive sense not knowing the reason for std::filesystem::path and
using the other paths.

Could make some documentation that explains the mechanisms of Path and what exactly it's invoking. Other developers won't really need to know if it's cross-platform or not and can happily carry on.

OR, what about making a class Path that handles the boiler-plate of conversion from std::string to std::filesystem::path, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something likePath path to std::filesystem::path pathto be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existing Path

Both routes I think are effective and that's the real question.

Hello everyone! I'd like to work on the project Nix Internals: Use std::filesystem::path for Path. I see there are others already interested in that project, so I do not mean to bring unwanted competition. Nevertheless, C++ is my preferred language, so I really like the idea of following cxx 17 standards. Also, I've had some experience with cross-dev unix-to-windows (a nightmare), and I like the mission goal of bringing anything unix to windows (hence, the cross-dev). My experience with nix is setting up containerized dev environments to keep things consistent for multiple users, so I really believe in nix and think it's a highly effective tool for something that is otherwise a complete nightmare.

I could have more experience because I don't daily-drive. My platform is using nix package manager on gentoo w/ openrc init. Can operate in a more integrated environment (nixos, systemd + nix) if this is a problem.
Skills are C, C++, sh, (some) lisp

Sorry for being a little late to the party.. chaotic last weeks - open to other suggestions, if we're trying to spread proposals

Couple thoughts:

instead of changing instances of Path to std::filesystem::path, what about changing typedef std::string to typedef std::filesystem::path - then working from
there. Keeps interface the same for other developers and follows pre-established naming conventions. Looks better being grouped with CanonPath, Path, etc. and makes more intuitive sense not knowing the reason for std::filesystem::path and
using the other paths.

Could make some documentation that explains the mechanisms of Path and what exactly it's invoking. Other developers won't really need to know if it's cross-platform or not and can happily carry on.

OR, what about making a class Path that handles the boiler-plate of conversion from std::string to std::filesystem::path, and if that boiler-plate is done successfully then it solves the problem at its root.

Are you SET on changing something likePath path to std::filesystem::path pathto be explicit of what the object is/don't want to mess around with any naming convention benefits of keeping the existing Path

Both routes I think are effective and that's the real question.

Hello everyone! I'd like to work on the project Nix Internals: Use std::filesystem::path for Path. I see there are others already interested in that project, so I do not mean to bring unwanted competition. Nevertheless, C++ is my preferred language, so I really like the idea of following cxx 17 standards. Also, I've had some experience with cross-dev unix-to-windows (a nightmare), and I like the mission goal of bringing anything unix to windows (hence, the cross-dev). My experience with nix is setting up containerized dev environments to keep things consistent for multiple users, so I really believe in nix and think it's a highly effective tool for something that is otherwise a complete nightmare.

I could have more experience because I don't daily-drive. My platform is using nix package manager on gentoo w/ openrc init. Can operate in a more integrated environment (nixos, systemd + nix) if this is a problem.
Skills are C, C++, sh, (some) lisp, (some) perl

Sorry for being a little late to the party.. chaotic last weeks - open to other suggestions, if we're trying to spread proposals

A question about the pnpm idea: was this PR taken in mind? https://github.com/NixOS/nixpkgs/pull/290715
Is this considered a valid approach to pnpm dependency locking, or did the idea author have something else in mind?

I'm asking this because the idea's description states:
(...) this should be a non problem for us if we use a fod fetcher like the nixpkgs npm tooling. Some packages use a fetcher without strong reproducibility guarantees.
Which IMO seems to describe the FOD created in that PR

A question about the pnpm idea: was this (draft) PR taken in mind? https://github.com/NixOS/nixpkgs/pull/290715
Is this considered a valid approach to pnpm dependency locking, or did the idea author have something else in mind?

I'm asking this because the idea's description states:
(...) this should be a non problem for us if we use a fod fetcher like the nixpkgs npm tooling. Some packages use a fetcher without strong reproducibility guarantees.
Which IMO seems to describe the FOD created in that PR

A question about the pnpm idea: was this (draft) PR taken in mind? https://github.com/NixOS/nixpkgs/pull/290715
Is this considered a valid approach to pnpm dependency locking, or did the idea author have something else in mind?

I'm asking this because the idea's description states:
(...) this should be a non problem for us if we use a fod fetcher like the nixpkgs npm tooling. Some packages use a fetcher without strong reproducibility guarantees.
Which IMO seems to describe the FOD created in that PR

If it's a valid approach and therefore could be used as starting ground for e.g a makePnpmPackage function of sorts, is this idea still on the table for GSoC?

I've submitted my proposal through Google's dashboard for "Nix Internals: Use std::filesystem::path for Path". Please review and let me know if you'd like more information put into the proposal.
Thanks

cc: John Ericson