Skip to content
This repository has been archived by the owner on Sep 13, 2023. It is now read-only.

.mlem/env is ignored by a standard Python .gitignore #369

Closed
aguschin opened this issue Aug 2, 2022 · 3 comments
Closed

.mlem/env is ignored by a standard Python .gitignore #369

aguschin opened this issue Aug 2, 2022 · 3 comments
Labels
git Working with Git in MLEM .mlem/ Everything inside .mlem folder
Milestone

Comments

@aguschin
Copy link
Contributor

aguschin commented Aug 2, 2022

As reported by @alex000kim, .mlem/env gets ignored if you use the standard Python gitignore file.

To avoid this, we need to rename .mlem/env to .mlem/environment or something else.

@aguschin aguschin added the git Working with Git in MLEM label Aug 2, 2022
@aguschin aguschin added this to the Q3 milestone Aug 2, 2022
@aguschin aguschin changed the title .mlem/env is listed in gitignore .mlem/env is ignored by a standard Python .gitignore Aug 2, 2022
@itstargetconfirmed
Copy link
Contributor

Pull Request No: 369

GitHub Link: #369

Decided Approach:

In the current version of MLEM, when a MlemObject is saved, it is stored in .mlem/{object_type}/. We can see that the directory name used to store the MlemObject is therefore strongly coupled to its object_type. To prevent this, we can introduce a new property object_dir which will be used as the object’s storage directory name, thus decoupling the object’s storage directory name from its object_ type.

MlemEnv will be the only MlemObject in the current version of MLEM where its object_type value will differ from its object_dir value. The value of object_type will be env and the value of object_dir will be environment.

We will need to introduce a default object_dir value for other MlemObjects like MlemDeployment, MlemModel, MlemLink etc. We will set the value of object_dir to the respective object_type value for each MlemObject type as there is no need to change the storage directory name for these MlemObjects currently.

Alternative Approaches:

Initially, I thought that it would be more appropriate and easier to change the object_type of MlemEnv from env to environment, however, this would require the user to type environment as opposed to env when defining their target environment and performing other environment related operations. It is quite lengthy to type environment as opposed to env which may be a bad user experience. Additionally, it does not solve the issue of decoupling the object’s storage directory name from its object_type, therefore I opted for introducing a new property, object_dir as discussed initially. I did however test changing the object_type from env to environment for completeness and the implementation worked without any issues.

Related Tasks:

If this approach is accepted and merged, then I’ll also update the mlem.ai website to include information about the object_dir property. I’ll update the following:

  1. The basic concepts page to explain that object_dir is a common field on MlemObject and describe its purpose. Link: https://mlem.ai/doc/user-guide/basic-concepts

  2. The project structure page to explain that a MlemObject will be stored in the directory defined by its object_dir as opposed to its object_type. Link: https://mlem.ai/doc/user-guide/project-structure

@mike0sv
Copy link
Contributor

mike0sv commented Sep 13, 2022

Hi @itstargetconfirmed! Thank you for this detailed description! This is a good solution, however right now we considering to get rid of .mlem dir completely (#381) so this issue should be postponed until we reach a conclusion in that matter

@aguschin aguschin added the .mlem/ Everything inside .mlem folder label Sep 16, 2022
@aguschin
Copy link
Contributor Author

aguschin commented Nov 8, 2022

We got rid of .mlem/ dir eventually. So, closing this!

@aguschin aguschin closed this as completed Nov 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
git Working with Git in MLEM .mlem/ Everything inside .mlem folder
Projects
None yet
Development

No branches or pull requests

3 participants