Release v0.0.1

Author: Ritik Gupta

README.md

@@ -1,2 +1,35 @@
-# find-dict-path
-Pythonic Dictionary path generator 
+# Pyhtonic Dictionary Path Generator
+A package used to the get the Full Pythonic Dictionary Path of the Search key .
+
+## How to use
+_After installing the package use following import:_ <br>
+
+```Python
+from find_dict_path import Find_Dict_Path
+
+search_key_from_dict = {"full name":"Brendan Stiedemann","address":{"street":{"colony":"Reinger Inc","extra_info":[{"date":"2023-05-06"},{"uuid":"6eca8033-ba89-4db2-bdb1-c2e0a4f6e0e6"},{"phone":"615-335-1131"}]}}} 
+
+search_key = 'phone'
+
+search_path_finder_from_dict = Find_Dict_Path()
+
+full_path = search_path_finder_from_dict.get_full_path(search_dict,'propEmbed')
+
+print(full_path)
+
+#['address']['street']['extra_info'][2]['phone']
+ 
+```
+
+_If you wants to get path in every occurrence of the list within dictionary then we can use `find_first_occurance=False` by default it is set as True _ <br>
+
+```Python
+full_path = search_path_finder_from_dict.get_full_path(search_dict,'propEmbed',find_first_occurance=False)
+
+print(full_path)
+
+#['address']['street']['extra_info'][*]['phone'] 
+```
+
+> **_NOTE:_**  In output path [*] represent the List is present.
+

app/__init__.py

@@ -0,0 +1,3 @@
+from find_key_in_dict import (
+    Find_Dict_Path
+)

app/find_dict_path/__init__.py

@@ -0,0 +1,52 @@
+from typing import List
+
+
+class Find_Dict_Path:
+    
+    def __init__(self) -> None:
+        self.ans=[]
+
+
+    def get_full_path(self,raw_dict_list_data:dict,search_key_name:str,find_first_occurance:bool=True) -> str:
+        self.ans=[]
+        self.__find_full_path_of_key(raw_dict_list_data,search_key_name,find_first_occurance)        
+        return self.__get_path_formatter()
+        
+    def __get_path_formatter(self) -> str:
+        
+        if self.ans==[]:
+            return "[]"
+        
+        formatted_path=""
+        
+        for sub_path in self.ans:
+            if isinstance(sub_path,int) or sub_path=="*":
+                formatted_path+=f"[{sub_path}]"
+            else:
+                formatted_path+=f"['{sub_path}']"
+                
+        return formatted_path
+    
+    def __find_full_path_of_key(self,raw_dict_list_data:dict,search_key_name:str,find_first_occurance:bool=True) -> bool:
+        
+        if isinstance(raw_dict_list_data,list):
+            for index,single_list_data in enumerate(raw_dict_list_data):
+                result=self.__find_full_path_of_key(single_list_data,search_key_name,find_first_occurance)
+                if result:
+                        self.ans.insert(0,index if find_first_occurance else "*")
+                        return True
+                
+        if isinstance(raw_dict_list_data,dict):
+            for key,value in raw_dict_list_data.items():
+                if key==search_key_name:
+                    self.ans.insert(0,key)
+                    return True
+                else:
+                    result=self.__find_full_path_of_key(value,search_key_name,find_first_occurance)
+                    if result:
+                        self.ans.insert(0,key)
+                        return True
+                        
+        return False
+    
+    

app/find_dict_path/find_key_in_dict.py

@@ -0,0 +1,89 @@
+## Introduction
+
+- Python packaging is the most common way to share code/libraries/applications. It allows packaging of the modules, so that they can later be published and deployed by other users, either by sharing binary files, source code or by using a package manager to fetch them from online (public or private) repositories.
+- The recommended way to package your code is by using the built-in python library _setuptools_ which has a lot and powerful functionalities.
+- In this video, I ll show you how to harness some the power of _setuptools_ so that you can package and publish your code on the official python repository _PyPI._
+- Stay with me until the end of the video, where I will present a cool and practical alternative to a common practice most developers do, but is not needed anymore when packaging your code.
+
+## Example use cases (where packaging is a must)
+
+- Easier management of release versioning
+- Shipping and deployment becomes pretty simple
+- Automatic dependency management
+- Increase your code’s accessibility
+- Cloud computing
+- Containerizing your application
+
+## Code example
+
+- Brief presentation of the library itself
+  - A library that contains various ID generators ( password, guid, valid credit card number, object id and numerical pin)
+  - Unit tests are also included
+- Explain how the project is structured, folders, sub-folders because it plays important role when you install the package on the installed structure.
+
+## Present setuptools
+
+- _setuptools_ is a (now standard) python library that facilitates packaging python projects by enhancing the _distutils_ library.
+- Important keywords/parameters of _setuptools_ to be aware of:
+  - wheel (.whl): A pre-built (zip) binary file, which is ready to be installed, that contains all the necessary information (code itself and metadata) for python package manager to install the package. To create one you should run `python setup.py bdist_wheel` within the shell. bdist stands for binary distribution.
+  - sdist (.tar.gz) : The source code distribution equivalent to wheel. A tar file (zip) that contains the source code together with the [setup.py](http://setup.py) file, so the user can re-built it. To create a source distribution run `python setup.py sdist`
+- The above two commands can be combined into one, if both distributions are desired. The output will be stored within the _dist_ folder that setuptools will create in the same level with [setup.py](http://setup.py) resides.
+- The build folder: Contains all the source code / modules that will be distributed.
+- egg-info: A directory placed adjacent to the project's code and resources, that directly contains the project's metadata. Replaced by wheels. (directly from Wikipedia)
+  - Python eggs are a way of bundling additional information with a Python project, that allows the project's dependencies to be checked and
+    satisfied at runtime, as well as allowing projects to provide [plugins](<https://en.wikipedia.org/wiki/Plug-in_(computing)>) for other projects. (quoting wikipedia)
+
+## Present [setup.py](http://setup.py)
+
+- Talk about the basic parameters (the ones already in our example [setup.py](http://setup.py) file), brief explanation on what each one is responsible for.
+- Explain in a nutshell how to customize the parameters it needs for [setup.py](http://setup.py) to work, mostly package dir and packages that allows setuptools to automatically find all the packages in our project structure (which is explained before in code example).
+- Mention that _\*\*init_\*\*.py needs to be present in every directory/folder in order for it to be seen as a package directory.
+- Mention that an alternative to adding the parameters in [setup.py](http://setup.py) (python file) you can screate a setup.cfg (configuration file) as well. But that’s outside the scope of this video.
+
+## Building and installing a package (sdist, wheel)
+
+- Run [setup.py](http://setup.py) using ‘_python [setup.py](http://setup.py/) bdist_wheel sdist’_ command. Explain that this creates both source code files and binary (.whl) file.
+- Then install package locally by running ‘_pip install idgenerator-0.0.x-py3-none-any.whl’._ Alternatively, you can also run _pip install ._ under the directory where [setup.py](http://setup.py) lives and will install your package directly, but that doesn’t the _dist_ folder which contains all the files needed for publishing in the PyPI repository. (up to you).
+- Optionally, explain how to update _.gitignore_ to ignore _build, dist and .egg-info_ files.
+- NOTE: The current [setup.py](http://setup.py) file is configured to also install the tests within the python environment. That is not the way it should normally happen, it happens only for the purposes of this demo. We can always change that for the video if you think it should happen otherwise.
+
+## Introducing PyPI
+
+- Explain what PyPI is in a nutshell, how to browse/search packages and see the metadata about it (set up the ground for when you publish your package later).
+- Maybe a catchy point is to mention that when you _pip install anything_ you are basically fetching from PyPI (surprisingly enough some people might not know this!).
+- Make an account so that you can publish a package. I would recommend to make a testPyPI account [https://test.pypi.org/](https://test.pypi.org/) so that you don’t actually publish under the official repository.
+- Optional but good practice, explain how to configure / create _.pypirc_ file, so authentication happens automatically when uploading your package to the repository. Also good for privacy issues when making the video that your token doesn’t get compromised.
+
+## Publishing the package on PyPI
+
+- Make sure you have _twine_ installed. That’s a good point to run ‘_pip install .[dev]’._ Twine is declared as a development dependency, so that will install it automatically together with the package itself.
+- Run _twine check dist/_ ,\* you should see tests passed for both source code and wheel file.
+- Run ‘_twine upload — repository testpypi dist/_’ ._ Assuming you have a _.pypirc\* file configured, that should work and publish your package to the testPyPI repo.
+- Small detail to be aware of: If you try to publish same version name as already published, testPyPI won’t allow it and you ll get an error. (see point 7 in retrospective)
+- Visit your package’s webpage so that viewers can see how the package looks published.
+- You can also create a new environment and install the newly published package via pip. You can do the same within the existing environment but always more neat to do on a fresh environment.
+
+## Further capabilities of packaging
+
+- This part is totally up to you, as in how much further you want to go. Take a look at retro to see what you think is worth mentioning more extensively here. Number 4, 11 for example might be such cases.
+- Some interesting capabilities worth discussed for sure imo within the context of this video is _‘pip install -e .’_
+
+## Hook sharing
+
+- Talk about the no need of _requirements.txt_ due to the [setup.py](http://setup.py) dev option. If you did the first bullet point of Publishing the package, you can call back to it.
+
+## Retrospective
+
+Things to keep in mind before diving into code packaging:
+
+1. How much does it make sense when you package your code? (Is your code easily re-usable/abstracted enough and ‘plug and play’ after deployment?)
+2. Are you packaging your code for own use (for example in different environment), or to share it easier with other developers? (Documenting it, creating a helper web-page might be a good idea, or even necessary in some cases)
+3. If you re planning to share your package with others, consider using a software license before. Have a look at [https://tldrlegal.com/](https://tldrlegal.com/) or [https://choosealicense.com/](https://choosealicense.com/) for understanding the most popular software licenses available.
+4. If the application requires extra data, should those data be incorporated in the module or linked externally (depending on size)?
+5. Are the code modules decoupled enough for the end user to utilize parts of the package if needed?
+6. Is the architecture good enough for further development and do the modules/submodules semantically make sense to be named/placed the way they are?
+7. To avoid the overhead of updating the package version manually every time versioning management modules might come handy (ex. bumpversion\***\*).\*\*** Plus you are avoiding publishing clashes (PyPI) that occur under a version number already published previously.
+8. Good practice to use as many classifiers applicable, so that it helps developers find your package easier by filtering and it provides some metadata as well. Check the available classifiers here [https://pypi.org/classifiers/](https://pypi.org/classifiers/)
+9. Instead of using [setup.py](http://setup.py) file (code) you can atlernatively use setup.cfg which is a configuration file instead.
+10. Avoid using distutils package, use always setuptools, which is an enhancement of the former.
+11. Always publish your code under a license. By not using any license when packaging your code you are not allowing anyone to use your code?

outline.md

@@ -0,0 +1,17 @@
+from idgenerator import (
+    generate_password,
+    generate_guid,
+    generate_credit_card_number,
+    generate_object_id,
+    generate_pin_number,
+)
+
+print(generate_password(length=8))
+
+print(generate_guid())
+
+print(generate_credit_card_number(length=16))
+
+print(str(generate_pin_number(length=4)))
+
+print(generate_object_id())

run.py

@@ -0,0 +1,24 @@
+from setuptools import find_packages, setup
+
+with open("README.md", "r") as f:
+    long_description = f.read()
+
+setup(
+    name="find_dict_path",
+    version="0.0.1",
+    description="An Pythonic Dictionary path generator ",
+    package_dir={"": "app"},
+    packages=find_packages(where="app"),
+    long_description=long_description,
+    long_description_content_type="text/markdown",
+    url="https://github.com/ArjanCodes/2023-package",
+    author="Ritik",
+    author_email="[email protected]",
+    license="MIT",
+    classifiers=[
+        "License :: OSI Approved :: MIT License",
+        "Programming Language :: Python :: 3.10",
+        "Operating System :: OS Independent",
+    ],
+    python_requires=">=3.5",
+)