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

Consider removing the workspace vs project distinction; bring back .nimble-links #133

Open
Araq opened this issue Aug 20, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@Araq
Copy link
Member

Araq commented Aug 20, 2024

Refs: #104

I grow more and more unhappy with Atlas's solution to how it manages things and its complexity. The distinction between project and workspace is annoying in practice as I typically have a single "projects" directory that should not be Atlas's workspace as there are too many unrelated projects in it.

The problem Atlas tries to solve is easy development of multiple projects at the same time. This does not necessarily require the notion of a workspace. Symlinks would also work but since these are not portable we can use Nimble's idea of using .nimble-link files.

In other words Atlas manages a single project that has a vendor/ or deps/ directory where its dependencies are stored. Either directly inside this directory or by a linkfile that links to where to find the project. This means the dependency graph always has a single root and thus the command line interface is simplified too. It is always clear what a "lockfile" is. It is also always clear where the nim.cfg goes and how it should be maintained.

@Araq Araq added the enhancement New feature or request label Aug 20, 2024
@Clonkk
Copy link

Clonkk commented Aug 20, 2024

The way I ended-up using Atlas :

Workspace/
  atlas.workspace
  nim.cfg # Contains path to deps/ and src/
  deps/atlas.lock # contains external deps
  projects/ # This is a submodule w/ private code that depends on deps. Libraries only, no binary
    config.nims 
    lib1/
    lib2/
  main/ # contains nim file compiled into binary
    main_service1.nim
    main_service2.nim      
  # non-nim stuff
  scripts/ # collections of bash scrips to deploy stuff (.rpm, .deb packager mostly)
  cfg/ # default config files to deploy when installing
    • Inside projects were a collection of private Nim libraries (they were submodules so not nimble package). In retrospect, it should have been a single submodule and not 1 repo / library.
      • The only reason I wanted a submodule was to keep track of the commit. This could be solved by having multiple atlas.lock file or a global one.
    • I used multiple, different workspace if I wanted to have variations e.g. :
Workspace/
  atlas.workspace
  nim.cfg # Contains path to deps/ and src/
  deps/atlas.lock # contains external deps
  projects/ # Submodule that can be a different commit hash or a different project entirely
    config.nims
    lib3/
    lib4/
      
  main/
    main_service3.nim
    main_service4.nim
    
  scripts/ # collections of bash scrips to generate installer (.rpb or .deb)
  cfg/ # default config files to deploy when installing   

So essentially :

  • I never used "multiple independent project per workspace" and used multiple workspace instead.
    • I used atlas workspace as a template to deploy services / binary (whatever)
  • I needed to differentiate private code from external code in a clear manner.
  • A pain point were external deps/ that were dependent on C library / shared object that had a global install version.
  • I used atlas env in the workspace to fix the compiler version (it was a bit annoying having to recompile each time so sometimes I would 'cheat' by using symlink to a global install between my workspace)

@jfilby
Copy link

jfilby commented Aug 22, 2024

What about a project tree? That way you could have a single project, or multiple projects organized in a tree.

@moigagoo
Copy link

moigagoo commented Aug 22, 2024

100% agree with the proposal. I tried and failed to use Atlas multiple times specifically because I it made me do the dance with my existing folder structure, which is, I assume, and more or less standard one:

  1. ~/Projects is where all my projects live.
  2. ~/Projects/projectname is there my project's nimble file sits.
  3. For multiservice projects it's ~/Projects/projectname/[service1, service2, etc.], each service dir with its own nimble file (if it's a Nim project).

@lou15b
Copy link

lou15b commented Aug 22, 2024

I am hoping that Atlas will expand the concept of "project" to allow the
development of several related Nim packages at the same time. As far as I can
understand, I have not yet seen this capability.

For example, one may be developing a UI package, which uses opengl and sdl2.
The project may include:

  • the UI package under development
  • a new package of opengl helpers, which is being developed
  • a new package of sdl2 helpers, also being developed
  • an enhanced version of some existing package, but the enhancements have not
    yet been solidified, so a PR has not yet been submitted for the package
  • ... and so on.

The project requires all of the above development packages to use the same
dependencies directory, which contains existing packages such as opengl and sdl2,
and also pointers to the packages under development.

What is missing is the ability to automatically generate links in the dependencies
directory, pointing to the packages under development.

This is a real need, at least for me. And I expect that others developing projects
of a significant size also have the same need.

Or have I missed something, and the capability already exists?

@Araq
Copy link
Member Author

Araq commented Aug 23, 2024

Or have I missed something, and the capability already exists?

There just isn't a need for it at all.

Instead of "atlas, use path/to/package/in/development" you would simply patch the nim.cfg with --path:path/to/package/in/development.

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

No branches or pull requests

5 participants